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

[Rick Taylor <[e-mail]>]

Hi Brian, Ed,

I personally agree with the ACME Sec review...  I think subjectAltName is the wrong field to be using for Node-ID in the certificate, and using it definitely ties our hands with Naming and Addressing to only use Node-IDs (and by extension Endpoint IDs) that map to RFC3986 valid formats.

@Brian,  Can you suggest some replacement text for the 3rd paragraph of 4.4.1 that meet the ACME suggestion?

Everyone else, do you consider the change to use a different field/type in the certificate to be a change that requires returning TCPCLv4 to the WG.  Note that doing this will delay BPv7 and BPSec as they are all bound together.

With my chair hat on, I would suggest that the current text specifies the wrong field to use, rather than specifying something functionally incorrect.

Cheers,

Rick


From: dtn [mailto:[e-mail]] On Behalf Of Birrane, Edward J.
Sent: 23 August 2021 17:12
To: Brian Sipos; R. Atkinson
Cc: Brian Sipos; [e-mail]
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Brian, 

  If I am reading the TCPCLv4 document correctly (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26) then the NODE-ID is optional, and instead a DNS-ID/IPADDR-ID may be used.

  If the bundle EID scheme (there may be more than dtn://) does not map cleanly to a fully qualified domain name or IP address, my intuition is that the DNS-ID/IPADDR-ID construct would need to be used instead.  

  Since this is a TCP convergence layer, we already need to map a domain name or an IP Address anyway. 

  If that is the correct interpretation, it may be useful to strengthen the wording in the draft, but I don’t think we need a technical change.

  Am I missing something here?

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
  

From: dtn <[e-mail]> On Behalf Of Brian Sipos
Sent: Friday, August 20, 2021 3:36 PM
To: R. Atkinson <[e-mail]>
Cc: Brian Sipos <[e-mail]>; [e-mail]
Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID Validation draft

APL external email warning: Verify sender [e-mail] before clicking links or attachments
 
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