Subject: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 14:06:42 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The validation process for the signature computed in Section 4 seems
underspecified.

For example, let’s consider the example in Appendix A.  Through a whois query
for 192.0.2.0 one finds a “remarks:        Geofeed <https url>” field which
leads to a geofeed file which had the detached CMS signature blob “# RPKI
Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What reference or
text guides how to validate that signature in the RPKI (akin to the level of
detail in Section 3.3 of RFC7909 or RFC6125)?

I’m inferring that the steps would roughly be:

** Download the end-entity certificate identified by the subjectKeyIdentifier
field via the pointer/URI in the “subjectInfoAccess”  field extracted from the
CMS signature blob

** Download the intermediate certificate identified by the
authorityKeyIdentifier field via the pointer/URI in the “caIssuer” field
extracted from the CMS signature blob

** Based on the RIR identified in the whois query, download the RPKI trust
anchor of the RIR

** Validate the certificate chain from the RPKI trust anchor down to the
end-entity certificate.  Check that all of the basicConstraints,
certificatePolicies, etc. are accurate.  Check the CRL.

** Verify that the end-entity certificate contains the IP address of interest
(192.0.2.0) in the sbgp-ipAddrBlock field

** Validate the signature using the algorithm identified in the CMS signature
blog using the end-entity certificate

Is that the process?  Is that stated somewhere in the document or available via
reference?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Kyle Rose for the SECDIR review.

** Section 3.  "It is only used to authenticate a pointer to the geofeed file
and transport integrity of the data."

To separate the notion of the transport security provided with TLS and the
object security provided by the RPKI signature, it might be cleaner to say:

TLS and the web PKI authenticate the domain name in the URL and provides
confidentiality and integrity for the geofeed file in transit.

** Section 4.  Per “Borrowing detached signatures from [RFC5485] …”, I’m having
trouble following which concept is being borrowed to elevate this to a
normative reference.

** Section 4.  Per “the RPKI certificate covering the inetnum: object's address
range is included in the [RFC5652] CMS SignedData certificates field”, can a
more specific statement be made to say that it would be the sbgp-ipAddrBlock
field in the certificate?

** Section 4.  Per the format of the signature appended to the geofeed file:
       # RPKI Signature: 192.0.2.0/24
       # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
       # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
       ...
       # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
       # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
       # End Signature: 192.0.2.0/24

-- Are the header “# RPKI Signature: 192.0.2.0/24” and footer “# End Signature:
192.0.2.0/24” syntactically required?  If would seem so, but that’s never
explicitly stated and can only be inferred via the example.  It would be
helpful to explicitly clarify that.

-- Is that header case sensitive (e.g., is “rpki SiGnAtUrE:” equally valid?)?

-- The does the label “192.0.2.0/24” relate to the rest of the geofeed file and
the inetnum: value?

** Section 6. Privacy Considerations.

Unfortunately, [RFC8805] provides no privacy   guidance on avoiding or
ameliorating possible damage due to this
   exposure of the user.  In publishing pointers to geofeed files as
   described in this document, the operator should be aware of this
   exposure in geofeed data and be cautious.  All the privacy   considerations
   of [RFC8805] Section 4 apply to this document.

Isn’t the different between RFC8805 which provided the underlying format shared
“ad hoc feed discovery and verification [that have] a modicum of established
practice” and this document from a privacy perspective that this work would
create an API-of-sorts with the potential of dramatically increasing access and
ease of IP-to-location information?

** Appendix A.

Section 4 says: “As the signer specifies the covered RPKI resources relevant to
the signature, the RPKI certificate covering the inetnum: object's address
range is included in the [RFC5652] CMS SignedData    certificates field.” I was
expecting the end-entity certificate to encode “192.0.2.0/24” in the
sbgp-ipAddrBlock field.  The CA certificate has this IP block, but the
end-entity certificate decodes the sbgp-ipAddBlock field to “IPv4: inherit
IPv6: inherit”.  Is that expected -- to have both an ipv4 and ipv6 annotation
(since the previous certificate in the chain only mentioned IPv4), and not
explicitly repeat the IPv4 value?

** Editorial

-- Abstract.  Typo. s/Intrastructure/Infrastructure/

-- Section 1.  Editorial. Per “An optional, utterly awesome but slightly
complex means …”, what does the colloquial “utterly awesome” add?

-- Section 2.  Editorial.
   This document also suggests optional signature, which authenticates
   the data when present, for geofeed files to provide stronger
   authenticity to the data.

Saying “authenticates” and “authenticity” in the same sentence made it
difficult parse.  Likewise,   s/suggests optional signatures/suggests an
optional signature/.  Perhaps: NEW This document also suggests an optional
signature to strongly authenticate the data in the geofeed files.

-- Section 3. Typo. s/contol/control/

-- Section 3.  Typo. s/survery/survey/

-- Section 5.  Editorial.  Consider not using “fetching with tweezers” for
additional clarity.

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 May 2021 11:27:27 -0400

Roman:

Addressing some of your comments below.  I'm leaving others to my co-authors.

I suggest the following changes in Section 4:

OLD:

   Validation of the signing certificate needs to ensure that it is part
   of the current manifest and that the resources are covered by the
   RPKI certificate.

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the
   other hand, verifying the signature requires no complexity; the
   certificate, which can be validated in the public RPKI, has the
   needed public key.

NEW:

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the
   other hand, verifying the signature requires no complexity; the
   certificate, which can be validated in the public RPKI, has the
   needed public key.

   The trust anchors for the RIRs are expected to already be available
   to the party performing signature validation.  Validation of the CMS
   signature on the geofeed file involves:

   1.  Obtain the signer's certificate from an RPKI Repository.  The certificate
       SubjectKeyIdentifier extension [RFC5280] MUST match the
       SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652].
       If the key identifiers do not match, then validation MUST fail.

   2. Construct the certification path for the signer's certificate.  All of
       the needed certificates are expected to be readily available in the
       RPKI Repository.  The certification path MUST be valid according to
       the validation algorithm in [RFC5280] and the additional checks
       specified in [RFC3779] associated with the IP Address Delegation
       certificate extension and the Autonomous System Identifier Delegation
       certificate extension.  If certification path validation is unsuccessful, then
       validation MUST fail.

   3. Validate the CMS SignedData as specified in [RFC5652] using the
       public key from the validated signer's certificate.  If the signature
       validation is unsuccessful, then validation MUST fail.

   4. Verify that the IP Address Delegation certificate extension [RFC3779]
       covers the address range of the geofeed file.  If the address range is
       not covered, then validation MUST fail.

   If all of these steps MUST be successful to consider the geofeed file
   signature as valid.

The RPKI signature ought to be sufficient to consider the signature valid.  The
WebPKI is providing authentication and integrity of the fetched data, but if any
of the data is modified at any point in the process, the RPKI signature will catch it.

> trouble following which concept is being borrowed to elevate this to a

With the changes to address your DISCUSS, this can probably be an informational reference.

> field in the certificate?

I think this is already explained in the definition of 'covers'.  Am I missing something?

> helpful to explicitly clarify that.

Yes, they are required.  Randy, can you suggest a MUST statement?

> explicitly repeat the IPv4 value?

This will be done when the CA is issuing a subordinate certificate explicitly for geofeed signing.  This is good key hygene to use a given key for only one purpose.

Russ

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 19 May 2021 21:59:49 +0000

Hi Russ!

Inline ...

> -----Original Message-----
> From: Russ Housley <[email-masked]>
> Sent: Wednesday, May 19, 2021 11:27 AM
> To: Roman Danyliw <[email-masked]>
> Cc: IESG <[email-masked]>; [email-masked];
> [email-masked]; Ops Area WG <[email-masked]>; George Michaelson
> <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-
> 10: (with DISCUSS and COMMENT)
> 
> Roman:
> 
> > Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What
> > reference or text guides how to validate that signature in the RPKI
> > (akin to the level of detail in Section 3.3 of RFC7909 or RFC6125)?
> >
> > ** Download the end-entity certificate identified by the
> > subjectKeyIdentifier field via the pointer/URI in the
> > “subjectInfoAccess”  field extracted from the CMS signature blob
> >
> > authorityKeyIdentifier field via the pointer/URI in the “caIssuer”
> > field extracted from the CMS signature blob
> >
> > ** Based on the RIR identified in the whois query, download the RPKI
> > trust anchor of the RIR
> >
> > ** Validate the certificate chain from the RPKI trust anchor down to
> > the end-entity certificate.  Check that all of the basicConstraints,
> > ** Validate the signature using the algorithm identified in the CMS
> > signature blog using the end-entity certificate
> >
> > Is that the process?  Is that stated somewhere in the document or
> > available via reference?
> 

Works for me.  Thanks for precisely stating the CMS field names which would not have been recognizable from my above short hand notation.

> > ** Section 3.  "It is only used to authenticate a pointer to the
> > geofeed file and transport integrity of the data."
> >
> > To separate the notion of the transport security provided with TLS and
> > the object security provided by the RPKI signature, it might be cleaner to say:
> >
> > TLS and the web PKI authenticate the domain name in the URL and
> > provides confidentiality and integrity for the geofeed file in transit.
> 
> > ** Section 4.  Per “Borrowing detached signatures from [RFC5485] …”,
> > I’m having trouble following which concept is being borrowed to
> > elevate this to a normative reference.
> 

Agreed.

> > ** Section 4.  Per “the RPKI certificate covering the inetnum:
> > object's address range is included in the [RFC5652] CMS SignedData
> > certificates field”, can a more specific statement be made to say that
> > it would be the sbgp-ipAddrBlock field in the certificate?
> 

With the precision you provided in the response to the DISCUSS, I would have rephrased my original comment to:

NEW
... the RPKI certificate covering the inetnum: object's address range is included in the IP Address Delegation certificate extension [RFC3779] field.

> > object's address range is included in the [RFC5652] CMS SignedData
> > certificates field

> >       #
> MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKo
> Z
> >       #
> IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7h
> Zu
> >       ...
> >       #
> imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
> > 192.0.2.0/24” syntactically required?  If would seem so, but that’s
> > never explicitly stated and can only be inferred via the example.  It
> > would be helpful to explicitly clarify that.
> 

I figured.  I'm thinking it just needs a sentence to say that.

> > ** Appendix A.
> >
> > Section 4 says: “As the signer specifies the covered RPKI resources
> > relevant to the signature, the RPKI certificate covering the inetnum: object's
> address
> > IPv6: inherit”.  Is that expected -- to have both an ipv4 and ipv6
> > annotation (since the previous certificate in the chain only mentioned
> > IPv4), and not explicitly repeat the IPv4 value?
> 
> This will be done when the CA is issuing a subordinate certificate explicitly for
> geofeed signing.  This is good key hygene to use a given key for only one
> purpose.

There was a CMS structure subtlety that I didn't understand.  The CA cert made no reference to v6, but the end-point one did.

Regards,
Roman

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 May 2021 18:11:20 -0400

Thanks Roman.  Two follow-up comments in line.

Russ

> On May 19, 2021, at 5:59 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Russ!
> 
> Inline ...
> 

I think this is resolved by the 4th item in the checking process.  That said, it would not be bad to highlight that earlier in the section.

> There was a CMS structure subtlety that I didn't understand.  The CA cert made no reference to v6, but the end-point one did.

Since the geofeed file in Appendix A only has an IPv4 address block, I should probably drop the IPv6:inherit.

Russ