On Mon, May 3, 2021 at 12:05 PM Russ Housley <housley@xxxxxxxxxxxx> wrote:
Explain how an attacker could get a client to accept a forged geofeed data file authenticated as I have suggested, because I'm not seeing it.We are not understanding each other. The RPKI signature will prevent the relying party from accepting a modified file, regardless of the means used to fetch it. For this reason, there is no need think about the interaction of the RPKI and the WebPKI. No dependency is being created.
I believe I understand entirely what you're saying. And I do not disagree with your conclusion. In the case of RPKI-signed geofeed data files, using https is unnecessary for integrity because the RPKI trust chain is authoritative for the response body and is sufficient to establish its authenticity. The only reason I can think of to require https for presumed-public geofeed data is if the mere fact of fetching it reveals something about the behavior of individual end users; this is true if CPE were to fetch the data, for instance, rather than the geo-authorization logic at the provider. If so, I think it worthwhile to explain this in the privacy considerations section.
Pivoting for a second, are you intending to support the case in which a provider has adopted RPKI but has no intention of signing these files? I.e., the hybrid case I alluded to, in which the routing data feed is protected (along with the geofeed URL) but the geofeeds themselves are not signed? If so, then web PKI integrity (i.e., being able to trust that the data at the https geofeed URL is controlled by the same entity that controls the routing data) is still required to prevent forgery.
Kyle
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
