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

From: "R. Atkinson" <[email-masked]>
Date: Wed, 11 Aug 2021 11:20:34 -0400

> On Jul 26, 2021, at 21:04, Brian Sipos <[email-masked]> 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

---

From: Brian Sipos <[email-masked]>
Date: Fri, 20 Aug 2021 15:35:32 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 23 Aug 2021 16:12:18 +0000

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 <[email-masked]> On Behalf Of Brian Sipos
Sent: Friday, August 20, 2021 3:36 PM
To: R. Atkinson <[email-masked]>
Cc: Brian Sipos <[email-masked]>; [email-masked]
Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID Validation draft

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> wrote:

> On Jul 26, 2021, at 21:04, Brian Sipos <[email-masked]<mailto:[email-masked]>> wrote:
>

Brian,

Yours,

Ran

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Rick Taylor <[email-masked]>
Date: Mon, 23 Aug 2021 19:38:29 +0000

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:[email-masked]] On Behalf Of Birrane, Edward J.
Sent: 23 August 2021 17:12
To: Brian Sipos; R. Atkinson
Cc: Brian Sipos; [email-masked]
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Brian, 

-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

APL external email warning: Verify sender [email-masked] before clicking links or attachments
 
All,

Brian,

Yours,

Ran

---

From: Brian Sipos <[email-masked]>
Date: Tue, 24 Aug 2021 16:20:05 -0400

Ed and Rick,
The fundamental issue is that tools can and do make assumptions beyond the
already incompatible requirement from RFC 5280 that a SAN URI have an
internet name (DNS FQDN or IP address), and there are some pre-existing
issues anyway with tools using SAN URI and PKIX certificate constraints.
The SAN extension is the right place to put it, but the "
uniformResourceIdentifier" type . Like some other aspects of IETF
protocols, where PKIX uses generic "URI" or similar terms what they really
mean (and what tools/libraries can assume) "internet name URI."

The change is to redefine what is a NODE-ID (it changes from a SAN URI to a
SAN otherName with a newly allocated type OID to specifically contain a DTN
EID value). This will require no change or conflict with RFC 5280 or
existing PKIX tooling or libraries. It will decouple the NODE-ID definition
from any earlier/other use of SAN URI. I can draft a modified TCPCL
document for these changes.

Rick, you are correct that the current definitions can be used in some
circumstances (the proof-of-concept implementation works fine with Node IDs
such as "dtn://node-A/") can run into problems when node names fall outside
of allowed DNS names (e.g. "dtn://_node_A/" or other disallowed DNS name
characters "dtn://_&@/") tools can rightfully refuse to either issue or
accept certificates with these SAN URIs.

On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <[email-masked]>
wrote:

> 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.
>
> 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
>
>
>   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.
>
>   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.
>
> Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group
> Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory
> 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
> 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

---

From: Brian Sipos <[email-masked]>
Date: Tue, 24 Aug 2021 16:35:01 -0400

One remaining technical decision about this is: does the SAN otherName
allow only Node ID values or any Endpoint ID values. This certificate
profile will only have a use for Node ID, but this restriction is related
to the SAN otherName type definition and not how that type is used by the
profile. From the tool perspective, it seems a little easier to allow the
type to contain any EID. A non-Node-ID value won't match any CL peer Node
ID so there's no harm in the otherName value being an EID.

On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <[email-masked]> wrote:

> The change is to redefine what is a NODE-ID (it changes from a SAN URI to
> a SAN otherName with a newly allocated type OID to specifically contain a
> DTN EID value). This will require no change or conflict with RFC 5280 or
> On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <
> [email-masked]> wrote:
>
>> Hi Brian, Ed,
>>
>> 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.
>>
>> 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.
>>
>> It would avoid many potential interoperability issues that were brought
>> up in the ACME discussion and require only slight change to a DTN

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 Aug 2021 08:06:49 +0000

Hi Brian,

From my reading of BPv7, a Node-ID is just an Endpoint ID with a special meaning (it’s the EID of the node itself, rather than another service on the node, or a multicast endpoint), so I suggest having the “otherName” OID registered as “DTN Endpoint ID” type.

There may be advantage to that flexibility beyond TCPCL, I can imagine use-cases where services may need to assert an identity just as a node does for TCPCL, and the generic “otherName” is the right tool for that job as well.

Cheers,

Rick

From: Brian Sipos [mailto:[email-masked]]
Sent: 24 August 2021 21:35
To: Rick Taylor
Cc: Birrane, Edward J.; R. Atkinson; Brian Sipos; [email-masked]
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

One remaining technical decision about this is: does the SAN otherName allow only Node ID values or any Endpoint ID values. This certificate profile will only have a use for Node ID, but this restriction is related to the SAN otherName type definition and not how that type is used by the profile. From the tool perspective, it seems a little easier to allow the type to contain any EID. A non-Node-ID value won't match any CL peer Node ID so there's no harm in the otherName value being an EID.

On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <[email-masked]<mailto:[email-masked]>> wrote:
Ed and Rick,
The fundamental issue is that tools can and do make assumptions beyond the already incompatible requirement from RFC 5280 that a SAN URI have an internet name (DNS FQDN or IP address), and there are some pre-existing issues anyway with tools using SAN URI and PKIX certificate constraints. The SAN extension is the right place to put it, but the "uniformResourceIdentifier" type . Like some other aspects of IETF protocols, where PKIX uses generic "URI" or similar terms what they really mean (and what tools/libraries can assume) "internet name URI."

The change is to redefine what is a NODE-ID (it changes from a SAN URI to a SAN otherName with a newly allocated type OID to specifically contain a DTN EID value). This will require no change or conflict with RFC 5280 or existing PKIX tooling or libraries. It will decouple the NODE-ID definition from any earlier/other use of SAN URI. I can draft a modified TCPCL document for these changes.

Rick, you are correct that the current definitions can be used in some circumstances (the proof-of-concept implementation works fine with Node IDs such as "dtn://node-A/") can run into problems when node names fall outside of allowed DNS names (e.g. "dtn://_node_A/" or other disallowed DNS name characters "dtn://_&@/") tools can rightfully refuse to either issue or accept certificates with these SAN URIs.

On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian, Ed,

Cheers,

Rick

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

Brian,

-Ed

---

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

All,

Brian,

Yours,

Ran

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 27 Aug 2021 21:55:35 +0000

Rick,

  Upon review, I agree with your (and Brian’s) statement that NODE ID should be preserved but not as a URL.

DTNWG,

  This document (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4) is currently in the RFC editor “EDIT” state. There will be an update to the document as part of responding to editor comments to produce a final version of the RFC. This update as part of the editor process can be used to correct errors in the document as they are identified.

  The question, of course, is whether the proposed correction to TCPCLv4 (for NODE ID use an otherName with a new OID for Endpoint ID) is a sufficient technical change to warrant restarting DTNWG technical review or whether this is a correction that can take place as part of the existing editing process.

  To that end, if you have a concern that this change requires more DTNWG technical review, please say so on this list.

  Alternatively, if you believe that this change should proceed with other corrections in the edit process, please post that as well.

-Ed

---

From: Rick Taylor <[email-masked]>
Sent: Wednesday, August 25, 2021 4:07 AM
To: Brian Sipos <[email-masked]>
Cc: Birrane, Edward J. <[email-masked]>; R. Atkinson <[email-masked]>; Brian Sipos <[email-masked]>; [email-masked]
Subject: RE: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

Hi Brian,

Cheers,

Rick

From: Brian Sipos [mailto:[email-masked]]
Sent: 24 August 2021 21:35
To: Rick Taylor
Cc: Birrane, Edward J.; R. Atkinson; Brian Sipos; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Cheers,

Rick

Brian,

-Ed

---

All,

Brian,

Yours,

Ran

---

From: <[email-masked]>
Date: Fri, 27 Aug 2021 15:01:25 -0700

I believe this change is not major enough to warrant additional DTNWG technical discussion but should instead proceed with other corrections in the edit process.

Scott

From: dtn <[email-masked]> On Behalf Of Birrane, Edward J.
Sent: Friday, August 27, 2021 2:56 PM
To: Rick Taylor <[email-masked]>; Brian Sipos <[email-masked]>
Cc: Brian Sipos <[email-masked]>; R. Atkinson <[email-masked]>; [email-masked]
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Rick,

DTNWG,

-Ed

---

Space Exploration Sector

 

From: Rick Taylor <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, August 25, 2021 4:07 AM
To: Brian Sipos <[email-masked] <mailto:[email-masked]> >
Cc: Birrane, Edward J. <[email-masked] <mailto:[email-masked]> >; R. Atkinson <[email-masked] <mailto:[email-masked]> >; Brian Sipos <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

APL external email warning: Verify sender [email-masked] <mailto:[email-masked]>  before clicking links or attachments

Hi Brian,

Cheers,

Rick

From: Brian Sipos [mailto:[email-masked]] 
Sent: 24 August 2021 21:35
To: Rick Taylor
Cc: Birrane, Edward J.; R. Atkinson; Brian Sipos; [email-masked] <mailto:[email-masked]> 
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <[email-masked] <mailto:[email-masked]> > wrote:

Ed and Rick,

On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <[email-masked] <mailto:[email-masked]> > wrote:

Hi Brian, Ed,

Cheers,

Rick

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

Brian, 

-Ed

---

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

APL external email warning: Verify sender [email-masked] <mailto:[email-masked]>  before clicking links or attachments
 
All,

On Wed, Aug 11, 2021 at 11:20 AM R. Atkinson <[email-masked] <mailto:[email-masked]> > wrote:

> On Jul 26, 2021, at 21:04, Brian Sipos <[email-masked] <mailto:[email-masked]> > wrote:
> 

Brian,

Yours,

Ran

_______________________________________________
dtn mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/dtn