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

From: Roman Danyliw <[email-masked]>
Date: Fri, 3 Sep 2021 14:13:09 +0000

Hi Brian!

On Wed, 01 September 2021 14:08 Brian Sipos <[email-masked]> wrote:

> All,
> I have a drafted (but not submitted to the datatracker) redline [1] to
> TCPCLv4 for the NODE-ID encoding changes discussed earlier. It adds one new
> IANA Considerations subsection for the otherName type and updates the one
> paragraph that uses that new type. This can be wordsmithed if anything
> seems vague or under-specified; specifically, there's no text explaining
> the nuance of "it can encode any Endpoint ID but for this PKIX profile it
> must contain only a Node ID". Something similar could be added if helpful.

Thanks for staging this diff.  The explicit mapping of NODE-ID to otherName seems like a good alternative, and it can be cascaded in the related ACME draft.

At the risk of re-opening some of the unrelated text, but in the spirit of being extremely explicit on how NODE-ID (Node ID), DNS-ID (DNS Name) and IPADDR-ID (Network Address) are expected to map into certificates in DTN, I noticed that the text in Section 4.4.1 only provide guidance on NODE-ID and IPADDR-ID.  The obvious is never said about DNS-ID.  Specifically:

NEW TEXT (to be symmetric with IPDADDR-ID)

   This specification defines a DNS-ID of a certificate as being the
   subjectAltName entry of type dNSName whose value is encoded
   according to [RFC5280].

Regards,
Roman

> [1]
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-dtn-tcpclv4-26.txt&url2=https://briansipos.github.io/dtn-bpbis-tcpcl/draft-ietf-dtn-tcpclv4.txt
>
>
>
> On Fri, Aug 27, 2021 at 5:55 PM Birrane, Edward J. <
> [email-masked]> wrote:
>
> 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
>
>
>
> ---
> 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:* Rick Taylor <[email-masked]>
> *Sent:* Wednesday, August 25, 2021 4:07 AM
> *To:* Brian Sipos <[email-masked]>
> *Cc:* Birrane, Edward J. <[email-masked]>du>; R. Atkinson <
> [email-masked]>gt;; Brian Sipos <[email-masked]>om>; [email-masked]
> *Subject:* RE: [dtn] [EXT] Re: Important side issues from ACME Node ID
> Validation draft
>
>
>
> *APL external email warning: *Verify sender [email-masked]
> before clicking links or attachments
>
>
>
> 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]
> <[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]> 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]> 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.
>
> @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,
>
>   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]>om>; [email-masked]
> Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID
> Validation draft
>
> APL external email warning: Verify sender [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]> wrote:
>
>
> > 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
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>

---

From: Brian Sipos <[email-masked]>
Date: Tue, 7 Sep 2021 21:25:11 -0400

Roman,
I have updated the pre-draft-submission changes to include the
explicit statement that TCPCL re-uses the DNS-ID from RFC 6125. I also
relocated the OID definitions (separate from IANA allocations) into a
"4.4.2.1.  PKIX OID Allocations" section to make it more clear that the
dtnEID otherName is *any* EID but this PKIX profile requires a more narrow
content of a Node ID.

After doing some prototyping, I added an Appendix B example of a dtnEID
otherName because it was not obvious during the implementation that I got
it right. For those familiar with URI encodings and the "dtn" URI scheme
definition, I think this use of IA5String is fine because the "dtn" scheme
only allows a restricted character set (no UTF8 here).

The same URI [1] works for the new content because it's pulled directly
from the git repository.

On Fri, Sep 3, 2021 at 10:13 AM Roman Danyliw <[email-masked]> wrote:

> Thanks for staging this diff.  The explicit mapping of NODE-ID to
> otherName seems like a good alternative, and it can be cascaded in the
> related ACME draft.
>
> At the risk of re-opening some of the unrelated text, but in the spirit of
> being extremely explicit on how NODE-ID (Node ID), DNS-ID (DNS Name) and
> IPADDR-ID (Network Address) are expected to map into certificates in DTN, I
> noticed that the text in Section 4.4.1 only provide guidance on NODE-ID and
> IPADDR-ID.  The obvious is never said about DNS-ID.  Specifically:
>

---

From: Brian Sipos <[email-masked]>
Date: Wed, 8 Sep 2021 09:50:03 -0400

All,
One last editorial change I'm going to make is to change the (newly added)
"dtnEID" to "bundleEID" for consistency with the actual phrasing in
RFC5050/BPbis of "Bundle Endpoint ID" and to more clearly separate the EID
from the "dtn" scheme which is only one option for that URI.

On Tue, Sep 7, 2021 at 9:25 PM Brian Sipos <[email-masked]>
wrote:

> dtnEID otherName is *any* EID but this PKIX profile requires a more
> narrow content of a Node ID.
>
>> At the risk of re-opening some of the unrelated text, but in the spirit
>> of being extremely explicit on how NODE-ID (Node ID), DNS-ID (DNS Name) and