On Mon, May 3, 2021 at 12:05 PM Russ Housley <hous...@vigilsec.com> 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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to