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

[Brian Sipos <[e-mail]>]

All,
After further discussion in the ACME WG (security area), based on a need to
avoid the requirements on DNS-name/IP-address and to avoid both valid and
invalid assumptions made by tools/libraries about SAN URI contents, the
strong recommendation is to avoid the SAN uniformResourceIdentifier
entirely in favor of a new SAN otherName type-id OID which is used just for
DTN EID (and thus Node ID) claims.

Unfortunately, this would require editing of a portion of the TCPCLv4 draft
now in the RFC editors queue, and a new IANA registration for the OID
under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [6].
Is this late edit an acceptable path for the document?
It would avoid many potential interoperability issues that were brought up
in the ACME discussion and require only slight change to a DTN
implementation to use a different SAN type (but identically encoded value).

[6]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

On Wed, Aug 11, 2021 at 11:20 AM R. Atkinson <[e-mail]> wrote:

>
>
> > 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
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>