Reviewer: Kyle Rose Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document Has Issues. == Nits The nits include a need for a thorough editorial pass prior to submission to the RFC editor. For example: * The abstract should probably give the uninformed reader a bit more information about the overall geofeed ecosystem. * "utterly awesome", "or whatever", "It would be polite" I would also move the privacy discussion from section 2 "Geofeed Files" to a privacy considerations section, as that is where those concerned will look for that information. == Unclear requirements This document appears to propose overlapping mechanisms for establishment of trust in geofeed data. As far as I can tell, geofeed data may be authenticated both by: * RPKI private key signature of a digest of a canonicalized form of the geofeed data file. * Web PKI via https URL for geofeed data file. I'm trying to suss out the requirements that led to this design, and so far it is not clear to me why two mechanisms are necessary or desirable given the complexity this implies for clients. ISTM that if a requirement is made that the geofeed data file MUST be served via https, and RPKI authenticates the URL, then the web PKI would provide a sufficient trust anchor for the geofeed data itself without any additional RPKI signature. Alternatively, if the assumption is that RPKI is the more appropriate PKI for protecting this information, then why leverage the web PKI at all? Moreover, even if the flexibility offered by two mechanisms is found to be desirable, there is no explicit recommendation that an LIR use one mechanism exclusively for a given geofeed. == Security gaps * There appears to be no way to revoke previously-signed geofeed data except via rotation of the RPKI key pair. Using the web PKI and https is a countermeasure here by preventing impersonation of the geofeed host, but it's unclear what utility RPKI provides if web PKI is required to guarantee geofeed freshness. Metadata imposing a expiry on geofeed data authenticated by RPKI would serve the same function, at the cost of requiring the data to be refreshed regularly. == Other questions * Is it always the case that RPKI private keys are protected by HSM, or is that simply a best practice? Is the assumption that all RPKI changes imply a manual workflow? * Is it actually the case that "the data change very infrequently"? Is there no legitimate use case for rapidly changing geofeed information, e.g., for overlay networks providing IP mobility? 'At most weekly' seems arbitrary. This also has implications for the choice of PKI, if manual workflows are indeed required for RPKI signing. * Why does the geofeed appendix not accommodate multiple signatures for distinct address ranges? The requirement that a geofeed file not be RPKI-signed in order to be shared by multiple INETNUM objects could be relieved were multiple signatures allowed. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
