Re: [dtn] Important side issues from ACME Node ID Validation draft

["R. Atkinson" <[e-mail]>]

> On Jul 26, 2021, at 21:04, Brian Sipos <[e-mail]> wrote:
> 
> The second issue is unfortunately more technical; the "dtn" URI scheme has been set in stone and is already in use, but the PKIX profile in [4] specifically requires that when any SAN URI which includes an authority part (the "dtn" scheme does, it is the node name) that authority is either a DNS name or IP address. And we know that a Node ID is _not_ going to contain a network-level name but some other name. This technically breaks the profile in [5] as well as [2], which both use SAN URI as Node ID authentication. Because neither RFC5280 nor RFC6125 require to dereference the SAN URI and the DTN PKIX profiles explicitly avoid the URI-ID definition of RFC6125, the only risk is really that some application may inadvertently try to DNS probe the node name (or something like that). I don't yet know how much of a blocking issue this will be, and it's unfortunate that it wasn't noticed earlier.

Brian,

DNS Operations folks consider “noise” DNS queries (such as an application trying to use DNS to resolve the node name or something similar) to be a significant operational challenge — because the volume of “noise” DNS queries already is high.

I imagine the DNS Operations folks would be greatly unhappy at the prospect of the DTN URI scheme being the cause of additional “noise” DNS queries.

A prospective change would be to update the PKIX profile in [4] to make clear that a dtn URI is neither a DNS name nor an IP address - ever.

In short, this looks like a real-world operational problem that will need _some_ form of solution, even if different from the prospective change I outlined just above.

Yours,

Ran