Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Randy: The consumer of geofeed data SHOULD fetch and process the data themselves. Importing datasets produced and/or processed by a third- party places significant trust in the third-party. >>> >>> this is in sec cons already. you want it moved up or duplicated? i >>> kinda like it where it is, but am flexible. >> >> I was not suggesting a new placement, just the edit to the last line. > > sorry. sure. > >> I propose adding that to the bottom of the paragraph that starts: >> >> If and only if the geofeed file is not signed per Section 5, ... >> >> By doing that, it does not conflict with the requirement in Section 5 >> that the address range of the signing certificate cover all prefixes >> in the signed geofeed file. > > When reading data from an unsigned geofeed file, one MUST ignore data > outside the referring inetnum: object's address range. This is to > avoid importing data about ranges not under the control of the > operator. Note that signed files MUST only contain prefixes within > the referring inetnum:'s range as mandated in Section 5. Fine with me. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
>>> The consumer of geofeed data SHOULD fetch and process the data >>> themselves. Importing datasets produced and/or processed by a third- >>> party places significant trust in the third-party. >> >> this is in sec cons already. you want it moved up or duplicated? i >> kinda like it where it is, but am flexible. > > I was not suggesting a new placement, just the edit to the last line. sorry. sure. > I propose adding that to the bottom of the paragraph that starts: > >If and only if the geofeed file is not signed per Section 5, ... > > By doing that, it does not conflict with the requirement in Section 5 > that the address range of the signing certificate cover all prefixes > in the signed geofeed file. When reading data from an unsigned geofeed file, one MUST ignore data outside the referring inetnum: object's address range. This is to avoid importing data about ranges not under the control of the operator. Note that signed files MUST only contain prefixes within the referring inetnum:'s range as mandated in Section 5. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Randy: >> >> Suggested edits: >> >> The address range of the signing certificate MUST cover all prefixes >> in the signed geofeed file. If not, the authenticator is invalid. >> >> The signing certificate MUST NOT include the Autonomous System >> Identifier Delegation certificate extension [RFC3779]. If it is >> present, the authenticator is invalid. >> >> 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]. If "inherit" is used, the >> authenticator is invalid. > > sure > >> The consumer of geofeed data SHOULD fetch and process the data >> themselves. Importing datasets produced and/or processed by a third- >> party places significant trust in the third-party. > > this is in sec cons already. you want it moved up or duplicated? i > kinda like it where it is, but am flexible. I was not suggesting a new placement, just the edit to the last line. >> I think is is probably better to drop the following from Section 6: >> >> When using data from a geofeed file, one MUST ignore data outside the >> referring inetnum: object's inetnum: attribute address range. > > this is meant for an unsigned file. e.g. multiple diverse inetnum:s > refer to the single geofeed file https://rg.net/geofeed. it allows an > operator not signing to maintain one file. > > all geofeeds are not signed for a number of reasons > > o rpki data may not exist for some, cf. decades of difficulty getting >rpki allowed by all RIRs. plus, you do not really want to tie the >two operational processes together. > > o geofeed data are not critical. they just hints to geoloc obsessed >content providers I propose adding that to the bottom of the paragraph that starts: If and only if the geofeed file is not signed per Section 5, ... By doing that, it does not conflict with the requirement in Section 5 that the address range of the signing certificate cover all prefixes in the signed geofeed file. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
> Suggested edits: > >The address range of the signing certificate MUST cover all prefixes >in the signed geofeed file. If not, the authenticator is invalid. > >The signing certificate MUST NOT include the Autonomous System >Identifier Delegation certificate extension [RFC3779]. If it is >present, the authenticator is invalid. > >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]. If "inherit" is used, the >authenticator is invalid. sure >The consumer of geofeed data SHOULD fetch and process the data >themselves. Importing datasets produced and/or processed by a third- >party places significant trust in the third-party. this is in sec cons already. you want it moved up or duplicated? i kinda like it where it is, but am flexible. > I think is is probably better to drop the following from Section 6: > >When using data from a geofeed file, one MUST ignore data outside the >referring inetnum: object's inetnum: attribute address range. this is meant for an unsigned file. e.g. multiple diverse inetnum:s refer to the single geofeed file https://rg.net/geofeed. it allows an operator not signing to maintain one file. all geofeeds are not signed for a number of reasons o rpki data may not exist for some, cf. decades of difficulty getting rpki allowed by all RIRs. plus, you do not really want to tie the two operational processes together. o geofeed data are not critical. they just hints to geoloc obsessed content providers randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Paul: I am writing to address #3 and #4. Thanks for your careful review. > #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? As the text says, we want canonical form to be the input to the signing process. This is unchanged from RFC 9092, which has not caused the interoperability concerns that you suggest. Also, this is the same approach that was used for digitally signing Internet-Drafts. > #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 ? I agree with the response that Job already offered. In short, RPKI certificates are issued to match the privileges required for the object that will verified with the public key. In this way, least privilege is always accomplished. Since Section 5 is option, authentication is optional. Thus, the Operational Considerations do include some discussion of unsigned geofeed files. Suggested edits: The address range of the signing certificate MUST cover all prefixes in the signed geofeed file. If not, the authenticator is invalid. The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]. If it is present, the authenticator is invalid. As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
thanks for review, paul > #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. please differentiate between change control of the document, and of RPSL. the ietf abandoned RPSL decades ago. > #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. please differentiate between - fetching a geofeed file pointed to by an inetnum: https url, and - fetching the rirs's published archive of all inetnums: and other rpsl objects >the RIR's FTP [RFC0959] services SHOULD be used that is bulk fetching the rpsl, not the geofeed > More seriously, can we avoid SHOULDing the FTP protocol? > Are these resources not made available over HTTP? one at a time with tweezers. don't do that. > 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. again, please differentiate between the bulk fetch of the rpsl via ftp and the fetch of individual geofeed files via https. > The geofeed files MUST be published via and fetched using HTTPS > [RFC9110]. > > Uhm. So what about FTP now? again, please differentiate between the bulk fetch of the rpsl via ftp and the fetch of individual geofeed files via https. > 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) again, the differentiateion between the rpsl data and the geofeed files is critical. > #3 Signature and white space requirements are a bit troubling > #4 Misc. Security comments more on these later, when russ has had a chance to comment > -- > 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" ? how about An application looking for geofeed data for 192.0.2.0/29, MUST ignore data in geofeed_1 because 192.0.2.0/29 is within the more specific 192.0.2.0/24 inetnum: covering that address range and that inetnum: does have a geofeed reference. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
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
