Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-finding-geofeeds-12: 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: ---------------------------------------------------------------------- Roman and Russ did the heavy lifting already, but I think I have a bit more fiddling to do regarding the validation procedures (just getting them internally consistent, I think)... (1) Here: 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. we say that the signing certificate is included in the SignedData certificates field. That makes sense, as SignedData is a SEQUENCE including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and CertificateSet, as a SET OF CertificateChoices, allows for the literal "Certificate" branch of CertificateChoices. But later on, we say that: 1. Obtain the signer's certificate from an RPKI Repository. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5286]. If the key identifiers do not match, then validation MUST fail. which entails fetching the certificate from a directory, based on the SubjectKeyIdentifier. Why do we need to obtain the certificate twice in two different ways? (2) We are careful to note that: The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present exactly as shown. How do we construct the bits (CIDR block?) that come after the quoted strings? Do they only matter for matching start/end, or are we supposed to check them in the validation procedure? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Kyle Rose for the secdir review, and all who participated in the subsequent discussion. Publishing this document on the stanards-track does make one wonder whether RFC 8805 should be adopted at least into the IETF stream and possibly to the standards-track as well... My colleagues have done a great job commenting on aspects that I also was unsure about; I will try (and no doubt fail) to deduplicate. The length of my comments notwithstanding, thank you for putting together this document: it seems useful without trying to boil any oceans, and I hope my comments can help improve it. Section 1 This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC2622] inetnum: class to refer Interestingly, I don't see "inetnum" at all in RFC 2622 (but the treatment in RFC 2725 is helpful to some extent). Should we be referencing 2725 (or something else) in addition to 2622? Section 3 The URL's use of the web PKI can not provide authentication of IP address space ownership. It is only used to authenticate a pointer to the geofeed file, [...] I'm a little confused by the use of the phrase "authenticate a pointer to the geofeed file". My understanding is that the "pointer to the geofeed file" is the URL itself, i.e., it is a pointer from the RPSL stanza to the geofeed file, and that dereferencing the URL retrieves the geofeed file itself (i.e., not a pointer). In particular, the URL (and any Web PKI usage therein) does not do anything to authenticate the RPLS stanza in which the URL appears. IIUC, it would be okay to just drop that bit and say "It is only used to authenticate the domain name in the URL, and provide confidentiality and integrity for the geofeed file in transit". Am I missing something? If a geofeed CSV file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects. We might note that such files with geofeed references from multiple inetnum: objects are not compatible with our signing procedure (right?) and thus vaguely discouraged. Section 4 address range. One needs a format that bundles the relevant RPKI certificate with the signature and the digest of the geofeed text. If the signature is distributed alongside the file being signed, why is it necessary to bundle the digest of the file being signed with the signature? This just invites security-relevant implementation bugs where the validator just accepts the precomputed digest and does not validate that the contents of the geofeed file actually have that digest. (There is, however, value in the CMS SignedData including the digest *algorithms* used in signatures. I don't know if that was the intent here.) text. Trailing space characters MUST NOT appear on a line of text. That is, the space or tab characters must not be followed by the <CRLF> sequence. [...] Is the restriction on Unicode characters of category "space separator" ("space characters") or the two listed characters? (Why just those two, and not form feed as well?) The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs; and therefore must be covered by the range of the inetnum:. Maybe I'm just confused about what "covered by he range of the inetnum:" means, but I only see (at least so far) requirements that the signing cert cover all addresses in the file, and that we fetch from the most-specific inetnum: object with a geofeed reference. Can't I still sign with a cert that covers a broader range of addresses than the intenum: object used to fetch? 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 I thought there was some previous discussion of this but now I can't find it: I assume that a HSM is not mandatory for holding the RPKI certificate's private key. In that case, I'd consider "getting the department that controls the private key (which might be trapped in a Hardware Security Module, HSM)". 1. Obtain the signer's certificate from an RPKI Repository. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5286]. If the key identifiers do not match, then validation MUST fail. We want RFC 5652 again, here (5286 is IP Fast Reroute: Loop-Free Alternates, which is of no relevance to this document). 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. "address range of the geofeed file" is probably under-specified, since the file could in theory include multiple disjoint ranges. I assume we want to say something like "covers all the addresses and/or address ranges in the geofeed file" and make the grammar in the last sentence match. 5. Validation of the signing certificate MUST ensure that it is part of the current manifest and that the resources are covered by the RPKI certificate. Is "the signing certificate" different from "the RPKI certificate"? Also, I suggest clarifying what "the resources" are that are covered. Also^2, "the current manifest" would be a great place to put in a reference to the relevant document(s) Section 5 If and only if the geofeed file is not signed per Section 4, then multiple inetnum: objects MAY refer to the same geofeed file, and the consumer MUST use only geofeed lines where the prefix is covered by the address range of the inetnum: object they have followed. Does "geofeed lines" here mean "lines/entries in the geofeed file", as opposed to "the geofeed: attribute in the intenum: class"? (Also, didn't we say earlier that geofeed files could have entries that don't map up to a CIDR block and thus don't have a well-defined prefix?) To minimize the load on RIR whois [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be the preferred access. This Preferred access for which objects/resources? If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI- signed geofeed file, a customer or attacker could publish an unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry which has weak authorization. I might reiterate that the rule for fetching from the most-specific inetnum: object with a geofeed reference means that the spoofed data will take effect (for the affected prefix), and possibly also that if validators could always require signatures, the attack would be stymied (but of course that is not happening anytime soon). Appendix A Those are some interesting Subject CNs in the non-root certs, but I guess they work... I only did some cursory spot-checking of the examples, and not a full work-up. NITS Section 1 of the service. This is often done using the source IP address used to contact the service. [...] I'd consider s/using/by using/ or s/using/based on/ Section 2 Content providers and other parties who wish to locate an IP address to a geographic locale need to find the relevant geofeed data. In I'd suggest s/to locate/to associate/ and high granularity can be quite large. The size of a file can be even larger if an unsigned geofeed file combines data for many prefixes, dual IPv4/IPv6 spaces are represented, etc. I'm not sure how the unsigned nature of the geofeed file is relevant for discussing its large size. Section 3 The Routing Policy Specification Language (RPSL), and [RFC2622] and [RFC4012] used by the Regional Internet Registries (RIRs) specifies Is the ", and" needed? Section 4 Should the authenticator be syntactically incorrect per the above, the authenticator is invalid. "The above" seems to be mostly discussing the geofeed file being signed, not the authenticator per se. Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] would be used to create a detached DER encoded signature which is Why "would be used" (vs "is used")? All of these steps MUST be successful to consider the geofeed file signature as valid. 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 last two paragraphs here seem to be copy/paste leftovers, as they (or a edited copy) already appeared prior to the detailed/enumerated validation procedure. [I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a Cryptographic Message Syntax (CMS) profile for a general purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI). It provides usable, albeit complex, code to sign geofeed files. I don't see any code in the draft itself ("provides"), but probably there is code referenced from it. Section 5 their RIR/NIR and/or any provider LIR which has assigned prefixes to Interestingly, RIR is not listed as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt (and LIR not listed at all!). This is the first time we use LIR, so we should expand it. It is good key hygiene to use a given key for only one purpose. To dedicate a signing private key for signing a geofeed file, an RPKI CA may issue a subordinate certificate exclusively for the purpose as shown in Appendix A. "subordinate certificate" seems to be a very uncommon phrase (and mostly only appears as part of "subordinate certificate authority"). Perhaps "a dedicated certificate" or "a leaf certificate" would work just as well? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
