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

[Brian Sipos <[e-mail]>]

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
>