Paul Wouters has entered the following ballot position for draft-ietf-opsawg-prefix-lengths-08: No Objection
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-prefix-lengths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Deb/Sean's DISCUSS on the ASN.1 module. The comments below I would have normally filed as a DISCUSS, but I think there is just no way to address these, and we will just have to wait for evolution in the RIR space to improve things. To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP [RFC0959] services SHOULD be used for large-scale access to gather I can't really ignore the fact that unsigned data is urged to be transfered in the clear possibly (likely?) without authentication. Why can this data not be made available over HTTPS ? (I understand RDAP might address this) [...] the authenticator is invalid. What does this mean? Should all the data be thrown away? Should it be processed as unauthenticated? If so, what would that mean in practise ? Similarly for: All of the above steps MUST be successful to consider the prefixlen file signature as valid. What if it is not valid? The prefixlen files MUST be published via and fetched using HTTPS [RFC9110]. Does this contradict this earlier statement? This document provides a guideline for how interested parties should fetch and read prefixlen files. To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP [RFC0959] services SHOULD be used for large-scale access to gather inetnum: instances with prefixlen references. Either this contradicts, or if the FTP fetch is to fetch data points that point to where to fetch prefixlen files, then an attacker can still fetch the prefixlen files over HTTPS, filter the signature(s), modify what it wants, then serve this over their own HTTPS server by updating the FTP fetch stream as MITM to point to its own HTTPS server? So I am not sure I can agree with the following text in the Security Considerations section: As mentioned in Section 6, some RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious prefixlen files. Section 6 suggests an unfortunately complex method for stronger authentication based on the RPKI. I think Section 6 still has an FTP fetch in its process that can be manipulated to bypass the stronger authentication? _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
