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
