Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Thanks Roman. Two follow-up comments in line. Russ > On May 19, 2021, at 5:59 PM, Roman Danyliw wrote: > > Hi Russ! > > Inline ... > >> -Original Message- >> From: Russ Housley >> Sent: Wednesday, May 19, 2021 11:27 AM >> To: Roman Danyliw >> Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org; >> opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson >> >> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds- >> 10: (with DISCUSS and COMMENT) >> >> Roman: >> >> Addressing some of your comments below. I'm leaving others to my co- >> authors. >> >>> -- >>> 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 ” 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? >> >> 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 MUS
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Hi Russ! Inline ... > -Original Message- > From: Russ Housley > Sent: Wednesday, May 19, 2021 11:27 AM > To: Roman Danyliw > Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org; > opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson > > Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds- > 10: (with DISCUSS and COMMENT) > > Roman: > > Addressing some of your comments below. I'm leaving others to my co- > authors. > > > -- > > 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 ” 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? > > 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 signatur
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Roman: Addressing some of your comments below. I'm leaving others to my co-authors. > -- > 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 ” 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? 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. > > > -- > COMMENT: > -- > > Thank you to Kyle Rose for the SECDIR
[OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
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 ” 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 R
