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

[Brian Sipos <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]> wrote:
>
>> Hi Brian!
>>
>> On Wed, 01 September 2021 14:08 Brian Sipos <[e-mail]>
>> 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. <
>> > [e-mail]> 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 <[e-mail]>
>> > *Sent:* Wednesday, August 25, 2021 4:07 AM
>> > *To:* Brian Sipos <[e-mail]>
>> > *Cc:* Birrane, Edward J. <[e-mail]>du>; R. Atkinson <
>> > [e-mail]>gt;; Brian Sipos <[e-mail]>om>;
>> [e-mail]
>> > *Subject:* RE: [dtn] [EXT] Re: Important side issues from ACME Node ID
>> > Validation draft
>> >
>> >
>> >
>> > *APL external email warning: *Verify sender
>> [e-mail]
>> > 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:[e-mail]
>> > <[e-mail]>]
>> > *Sent:* 24 August 2021 21:35
>> > *To:* Rick Taylor
>> > *Cc:* Birrane, Edward J.; R. Atkinson; Brian Sipos; [e-mail]
>> > *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 <[e-mail]>
>> 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 <
>> > [e-mail]> 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:[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]>om>; [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
>> >
>> >
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>