Dear Paul, I implemented support for validating Geofeed signatures in OpenBSD's RPKI implementation. Section 3 and 4 of your DISCUSS message relate to this implementation work.
My implementation here is based on draft-ietf-opsawg-9092-update: https://github.com/openbsd/src/blob/master/usr.sbin/rpki-client/geofeed.c The geofeed_parse() function is passed contents of the entire Geofeed file and the length, and then starts to parse the content, it should be fairly straightforward to follow if you are familiar with C. As to trailing lines, it seems pretty common practise for parsers to ensure that they consumed the whole thing and no bytes are left unparsed, as allowing (or not explicitly disallowing) trailing garbage may lead to a potential for malleability. The RPKI community (mostly folks around sidr...@ietf.org) in recent years has made an effort and good progress to ensure that object profiles contain *only* what's relevant for the validation at hand. This massively helps implementers, because when reading an instruction such as "The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]." - the implementer will know that AS Identifiers play absolutely no role in this context. If a superfluous extension is encountered the authenticator is invalid. Nowadays, all RPKI profiles are explicit in this regard. See for a comparable approach this IESG-approved draft: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rfc6482bis-09#name-roa-validation I understood the goal of the draft-ietf-opsawg-9092-update effort to be unambiguous, more explicit, prescriptive, and thus leaving nothing to the imagination of the implementer. As to re-use of keypairs: one certainly can issue multiple certificates with the same keypair, the advantage of 'one-time-use' EE certificates as used in this document is that the CA can revoke individual versions of the Geofeed file. If the certificate is 'recycled' (same serial, wide validity window) this property is lost. I think the 'SHOULD' is appropriate here because is hard or impossible for Relying Party implementations to actually force CAs to issue a certificate for each Geofeed file. Finally, I think what you might be missing is the natural language equivalent of "goto out;" (as is sprinkled throughout my geofeed.c file), but the draft (near the end of Section 5) concludes with: "All of the above steps MUST be successful to consider the geofeed file signature as valid." - which to me means that any deviation from the MUST's results in an invalid authenticator. Kind regards, Job On Tue, Feb 13, 2024 at 10:18:10AM -0800, Paul Wouters via Datatracker wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-opsawg-9092-update-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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > "Handling Ballot Positions" - see > https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > I have a number of DISCUSSes, none of which should be hard to address or talk > out :) > > #1 document track > > The document is Standards Track, and so are the docs is Obsoletes/Updates > ([RFC2725] and [RFC4012]), but the document also claims "change control > effectively lies in the operator community". Normally, that would mean the > IETF > publishes this as Informational. But of course that would raise the issue that > an Informational would Obsolete a Standards Track document. Some discussion on > this would be good. > > #2 Transport Security > > There are quite a few sentences scattered through the document about transport > security that are not aligned, see: > > The URL uses HTTPS, so the WebPKI provides authentication > > So is HTTPS mandatory? I guess not since (see below) FTP is allowed as URL > too. > > the RIR's FTP [RFC0959] services SHOULD be used > > To speak in the words of the great Monty Python, "An active or passive > swallow?" > > More seriously, can we avoid SHOULDing the FTP protocol? > Are these resources not made available over HTTP? If they are, can we > SHOULD that instead? Note the paragraph above it says: "Historically, > [...] often without consistent authentication". I wouldn't call that > "Historically" if you are are promoting FTP and allow "unsigned" files. > > The geofeed files MUST be published via and fetched using HTTPS > [RFC9110]. > > Uhm. So what about FTP now? > > The Security Considerations could bundle all the talk about HTTPS and FTP and > put in one clear clause here, mentioning that due to lack of universal > signing, > it is sadly super important to have transport security protection (eg HTTPS, > not FTP) > > #3 Signature and white space requirements are a bit troubling > > Trailing blank lines MUST NOT appear at the end of the file. > > That's rather strong. Should the file be rejected if a blanc line appears > at the end? If not, I wonder why to even mention this, especially with 2119 > force. Based on: > > If the authenticator is not in the canonical form described above, > then, the authenticator is invalid. > > That is a "yes the file should be rejected if it has a trailing blanc line". I > think that is unwise, I would like to hear the reasoning behind this. > > When present, such end-of-file markers MUST NOT be covered by the > digital signature. > > This is going to cause problems if people make detached signatures of the > file. > What is the reason for this requirement? > > The CMS signature does not cover the signature lines. > > This gets really complicated now, when we read the above item on blanc lines. > Does this mean the blanc line MUST NOT appear before these # comments? Or not > after these comments? Or both? Can there be a blanc line between geofeed > content > and signature? How about two blanc lines? > > #4 Misc. Security comments > > The address range of the signing certificate MUST cover all > prefixes in the signed geofeed file. > > I vaguely remember huge problems with such similar requirement. The document > is > not clear what to do when this is not the case? Reject everything? Or only > accept those entries that ARE covered? More guidance is needed here. > > The signing certificate MUST NOT include the Autonomous System > Identifier Delegation certificate extension [RFC3779]. > > What must one do if this does include it? > > As with many other RPKI signed objects, the IP Address Delegation > certificate extension MUST NOT use the "inherit" capability > defined in Section 2.2.3.5 of [RFC3779]. > > What must one do if this does include it? > > The Certificate Authority (CA) SHOULD sign only one geofeed file > with each generated private key and SHOULD generate a new key > pair for each new version of a perticular geofeed file. The CA > MUST generate a new End Entity (EE) certificate for each signing > of a particular geofeed file. > > When can these SHOULDs be ignored? Eg it _is_ possible to use the same key but > a different EE cert? Also, what is the reason for needing to generate a new EE > cert per geofeed version file? What issue is solved by not allowing a long > lived > EE cert to do this job? > > When using data from a geofeed file, one MUST ignore data outside > the referring inetnum: object's inetnum: attribute address range. > > How does this "MUST ignore" combine with the above mentioned "failed > validation" ? eg here it would seem an entry to 0.0.0.0/0 must be ignored, but > earlier text said to invalidate the entire file, not just the entry. So how > would we ever get here? > > If and only if the geofeed file is not signed per Section 5, > then multiple inetnum: objects MAY refer to the same geofeed > file, and the consumer MUST use only lines in the geofeed file > where the prefix is covered by the address range of the inetnum: > object's URL it has followed. > > We normally call this a downgrade attack. Strip the signature and modify the > file? Are there any counter measures that can be used to prevent this attack? > > Importing datasets produced and/or processed by a third-party > places ill-advised trust in the third-party. > > I don't think you can call all third-parties "ill-advised" by definition. > eg is "google DNS" and ill-advised third-party for DNS ? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since geofeed_1 contains geolocation data about 192.0.2.0/29, > it is discarded because 192.0.2.0/24 is within the more specific > inetnum: covering the address range and that inetnum: has a > geofeed reference. > > This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you meant > to say "a client looking for geofeed data for 192.0.2.0/29" ? > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
