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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
