On Thu, Apr 29, 2021 at 3:56 PM Randy Bush <randy@xxxxxxx> wrote:
> 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"
aha! the style directorate. we'll see how far it gets. maybe even
rfced still has a twinkle in their eye. :)
My point is simply that you should aim to submit the document in a form as close as possible to immediately publishable. Language that you and I and everyone else knows a priori is unsuitable for publication should get changed before submission. No reason to add busywork to the RFC editor's queue.
> 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.
aha. a privacy section is a new fashion of which i was unaware. done.
thanks.
I've simply observed it as a best practice to compartmentalize that kind of analysis in a place that readers expect, rather than sprinkling it throughout normative parts of the document.
> 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.
not exactly.
the web pki has no authority over IP address space ownership.
Understood. I'm not suggesting the web PKI be used to authenticate IP address space ownership. I'm suggesting that the following chain would be sufficient:
* RPKI authenticates the routing information, which includes the IP address space and the https URLs for each geofeed file.
* Web PKI authenticates the data served at that URL.
* Client verifies that the IP ranges in the geofeed data are contained within the (RPKI-authenticated) routing information.
I.e., you are chaining trust from the RPKI explicitly to the (https) URL, and implicitly to the data served from that URL. The web PKI is used only to ensure that the data is not modified in transit. It is not used to authorize IP address space ownership: regardless of the PKI used to authenticate the geofeed data, the client still needs to cross-check the IP ranges in the geofeed data against the ownership in the RPKI-authenticated routing information.
> it is
only used to authenticate a *pointer* to the geofeed file.
On the contrary, the pointer (i.e., the octet sequence making up the URL) is authenticated by RPKI in all cases. You're basically saying "Trust the data returned by the server at this URL." Which is a closed authentication chain if that URL is https by virtue of the corollary "Trust the web PKI to authenticate this server."
and the S in
https is just because we know folk will whine if the S is not there;
it's ietf fashion, similar to not working over ipv6 (or privacy
consideration sections:).
Thanks for illustrating why the security area reviews all documents prior to publication, and why the security directorate exists: because protocol security properties are often subtle and not reducible to a checklist.
> * 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.
validation of the signing certificate needs to ensure that it is part of
the current manifest and that the resources are covered by the RPKI
certificate. this handles revocation.
but, if you want to go down the "how does revocation work in the rpki"
rabbit hole, you have to drink the 3779 validation koolaid, and that of
the "up-down" protocol, and have a look at manifests. not that i am
recommending going down this rabbit hole.
I did a bit of digging, and it looks like RPKI does have revocation at the certificate level, so there is at least a (potentially costly) path to doing this.
> * Is it always the case that RPKI private keys are protected by HSM,
> or is that simply a best practice?
not at all. but, imiho, we should stay neutral on that. the example
Identifying the private key associated with the certificate, and
getting the department with the Hardware Security Module (HSM) to
sign the CMS blob is left as an exercise for the implementor.
was merely a cultural reference to the silos in a large LIR where
address space ownership, rpki signing, ... are often in a very separate
fiefdom from geo location folk.
I feel like this statement can be made in an implementation-neutral way, like "Signing workflows will vary and are out of scope for this document."
> * 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.
do we really want to start work on RFC5485-bis? but maybe russ has
better thoughts on this than i.
If signatures were detached, it would be trivial to have multiple. But that would complicate authentication for resources that are not immutable (e.g., inconsistent geofeed and signature files, something quite likely to happen with cacheable artifacts). So I wouldn't recommend that approach anyway. I guess my recommendation to simplify this would be twofold:
* Mandate RPKI for routing information, including the geofeed data URLs (i.e., the sequence of octets that represents a URL).
* Mandate the use of https (and therefore web PKI) for geofeed data (i.e., all URLs must be https://...)
This eliminates the need for the complexity of RPKI signatures in geofeed data while ultimately rooting that information in an RPKI trust anchor.
Kyle
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
