Subject: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

From: Roman Danyliw <[email-masked]>
Date: Fri, 23 Jul 2021 19:14:57 +0000

Hi!

I conducted an AD review of draft-ietf-acme-dtnnodeid-04.  Thanks for all of the work on this extension to support DTN.  My feedback is as follows:

** This document proposes an update to draft-ietf-dtn-bpbis.

-- Editorially, if that's the case, the document header has a typo of "-ietf-dtn-bpbis".  The abstract should explicitly state that what document is being updated and how.

-- On the process side, this arrangement is rather unusual.  No quarrels with the substance of the update which will improve extensibility.  However, this particular document has experimental status and the document being updated (draft-ietf-dtn-bpbis) is proposed standard (PS).  Having a lower maturity document updating one of higher status is my concern -- "experiments fail".  Was this issue considered?  Discussed with the DTN WG?  I'll note that draft-ietf-dtn-bpbis has not yet been published (although it is in the late state of the RFCEd queue).  Could the changes just be added there directly?

**I need a little help on DTN addressing.  The text notes that that the intent is to issue certificates with DTN Node IDs as a URI in subjectAltName.

(a) From the ABNF in Section 4.2.5.1.1 of draft-ietf-dtn-bpbis-31 of the dtn schema says:
   dtn-uri = "dtn:" ("none" / dtn-hier-part)

   dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

   node-name = 1*(ALPHA/DIGIT/"-"/"."/"_") reg-name

   name-delim = "/"

   demux = *VCHAR

(b) The dtn schema does have circumstances where there is an authority part to the URI.  The definition of reg-name in Section 3.2.2 of RFC3986 seems to suggest sufficient flexibility such that it would not represent a name valid (at least in syntax) in the DNS

(c) Section of 4.2.1.6 of RFC5280 says the following about URIs in the SAN:

   URIs that
   include an authority ([RFC3986], Section 3.2) MUST include a fully
   qualified domain name or IP address as the host.

Given the constraint of (c) and the flexibility afforded with the definition of a node ID in (a)+(b), will DTN Node IDs always satisfy the requirement from (c) to be FQDN?  Is language needed to ensure that (likely in a few places in the document)?

** Section 1.  Editorial.  The paragraph starting with "Once an ACME server validates ..." jumps immediately into discussion a "uri" without explicitly describing it.  The text also transitions from the previous paragraph talking DTN Node Ids being URIs and now talking about "uri".  I would have appreciate a bit more hand-holding use the ACME terminology of a new "identifier type" and the need for a new DTN specific "challenge type".

** Section 1.  
This document also updates BPv7 to explicitly use the IANA
   administrative record type registry in Section 6.

Please explicitly cite a reference to BPv7

** Section 1.2.

   When a ACME client requests a pre-authorization or an order with a
   "uri" having one of the DTN Node ID schemes, the ACME server offers a
   challenge type to validate that Node ID.  

As noted in section 1, please explicitly state that what a "uri" is - a new ACME identifier type.  I would recommend:

When a ACME client requests a pre-authorization or an order with a "uri" identifier type with a value being one of the DTN Node ID schemes, the ACME server offers an "dtn-nodeid-01" challenge type to validate that Node ID.  

** Figure 1.  For clarity, it would be helpful to number the arrows between nodes and also use the corresponding numbers in the narrative text.

** Section 1.3.  The explicit guidance on extracting the CDDL from the XML is very useful.  Thanks for including it.

** Section 1.4.  Per the definition of "Challenge Bundle", shouldn't text clarify that it's the BP agent of the ACME server?  The Response Bundle helpfully makes that distinction.
OLD
     It is a Bundle created by the ACME
      server to challenge a Node ID claim.

NEW
It is a Bundle created by the BP agent managed by the ACME
      server to challenge a Node ID claim.

** Section 2. 
   Identifiers of type "uri" in certificate requests MUST appear in an
   extensionRequest attribute [RFC2985] containing a subjectAltName
   extension of type uniformResourceIdentifier having a value consistent
   with the requirements of [RFC3986].  Because the
   uniformResourceIdentifier is encoded as an IA5String it SHALL be
   treated as being in the percent-encoded form of Section 2.1 of
   [RFC3986].  

Section 1 invokes the use of the PKIX profile [RFC5280].  The above described guidance is only part of the constraints on using a SAN on the URI.  Section 4.2.1.6 of [RFC5280] covers the rest.

** Section 3.  
   "token-chal"  This token is unique to, and constant for, each ACME
      authorization.  

This sentence reads to me as saying inconsistent things - "unique to ... each ACME authorization" suggests that each authorization gets a different token.  "... and constant for each ACME authorization" seems to suggest is the same token across all ACME authorizations.  That doesn't seem right.

** Section 3.  Editorially.  I found the validation process being described as two separate lists of action, one for the client and one from the server, instead of interleaving them hard to follow.  However, I yield to the WG on this one.

** Section 3.3.
   Source Node ID:  The Source Node ID SHALL indicate the Node ID of the
      ACME server performing the challenge.

Is it the "Node ID of the ACME server" or the "Node ID of the BP agent of the ACME server"  

** Section 3.4.  Typo. s/Each Each/Each/

** Section 3.4. Typo. s/the the/the/

** Section 3.4.1.

   *  The Response Bundle was received within the time interval allowed
      for the challenge.

It would be helpful to state if this check based is based on the Creation Time and Lifetime fields.

** Section 4.  The text here is generic describing the functionality of the gateway.  Figure 1 presented an architecture where only the Response Bundle would pass through the integrity gateway.  Is it envisioned that the Challenge Bundle could use it as well?

** Section 8.  It would be worth repeating that the Security Considerations of draft-ietf-dtn-bpbis apply to the BP-to-BP agent communication.  Likewise, that RFC8555 applies to the ACME client/server communication.

** Section 8.  Section 1.1 states that the communication between the ACME client and ACME server and their respective BP agents is out of scope.  However, the integrity of the entire ACME issuance process rests on security of this communication.  Can the risks of and considerations for that communication please be documented?

Regards,
Roman

---

From: Brian Sipos <[email-masked]>
Date: Tue, 27 Jul 2021 21:12:41 +0000

Roman,
Thank you for this thorough review. I want to address the more
procedural/structural points first; the ones which have implications outside of
just this document.

> On the process side, this arrangement is rather unusual.  No quarrels with the
substance of the update which will improve extensibility.  However, this
particular document has experimental status and the document being updated
(draft-ietf-dtn-bpbis) is proposed standard (PS).  Having a lower maturity
document updating one of higher status is my concern -- "experiments fail".  Was
this issue considered?  Discussed with the DTN WG?  I'll note that draft-ietf-
dtn-bpbis has not yet been published (although it is in the late state of the
RFCEd queue).  Could the changes just be added there directly?

BS: I did bring this up in the DTN WG earlier and the BPbis authors were fine
with the update itself, which didn't require BPbis document changes, but I
understand the concern about the different document status levels. I have
brought this new concern up in the DTN WG with options of either a late AUTH48
edit or a separate small Proposed Standard document from the DTN WG. The change
really is not specific to this ACME document but related only to this being the
first new administrative record type for BPv7.

> **I need a little help on DTN addressing.  The text notes that that the intent
is to issue certificates with DTN Node IDs as a URI in subjectAltName.
> ...
> Given the constraint of (c) and the flexibility afforded with the definition
of a node ID in (a)+(b), will DTN Node IDs always satisfy the requirement from
(c) to be FQDN?  Is language needed to ensure that (likely in a few places in
the document)?

BS: This is a good catch regarding conformance to RFC 5280, and unfortunately
represents a subtle logical conflict with this and another document [1].
Although Section 4.2.1.6 of RFC 5280 states this requirement about the URI
authority part it makes no other use of this authority restriction, and although
RFC 6125 does define a URI-ID which has matching logic based on the authority
part the certificate profile shared by DTN TCPCLv4 [1] and this document
explictly avoid using URI-ID in favor of the matching logic defined in [1] for
NODE-ID.
So while a "dtn" scheme URI contains an authority part which I believe meets the
intent of the RFC 5280 restriction (a unique and unambiguous name/address) it
does not meet the letter-of-the-law in that document. The dtn scheme is already
in use and has been for many years; although it resembles a URN in semantics it
does use a URL syntax which may be more of an historical accident than a design
decision (as the "ipn" scheme does not use the URL authority syntax).
Do you think that explicitly calling this out in this document and in [1] are an
acceptable way to avoid this logical issue? Meaning any CSR or certificate
handler for DTN must be aware to ignore that specific RFC 5280 requriement.

I think all of your other comments are sensible and I will respond to them
separately.
Thank you,
Brian S.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26#section-4.4.2