Subject: Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04 (others)

From: Brian Sipos <[email-masked]>
Date: Sat, 14 Aug 2021 16:19:54 -0400

Roman,
My replies regarding the other, editorial comments are below with the
prefix "BS:". I'll get back to the earlier topics in the other mail thread.

** 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".
>
> BS: I will add a third paragraph in that section to explain the new ACME
identifier and its rationale before using it.

> ** 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
>
> BS: Will do.

> ** 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.
>
> BS: Will do, this phrasing is more clear.

> ** Figure 1.  For clarity, it would be helpful to number the arrows between nodes and also use the corresponding numbers in the narrative text.
>
> BS: I agree, will add ordinal number hints to each flow.

> ** 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.
>
> BS: Will clarify this.

> ** 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.
>
> BS: I will rephrase to specifically point to RFC5280 as a direct
requirement here.

> ** 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.
>
> BS: I added a statement to clarify unique-to-authorization vs.
unique-to-challenge:

Each authorization can consist of multiple Challenge Bundles (e.g. taking
different routes), but they all share the same "token-chal" value.

and also the the "token-bundle" paragraph explaining:

This ensures that the Key Authorization is bound to the ability to receive
the Challenge Bundle and not just have access to the ACME Challenge Object.

> ** 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.
>
> BS: This was more due to taking existing ACME validation methods as
examples than any other driving concern. I suspect that is because the
client vs. server implementers have different communities of users.

** 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"
>
> BS: Yes, this is inaccurate and will be corrected.

> ** Section 3.4.  Typo. s/Each Each/Each/
>
> ** Section 3.4. Typo. s/the the/the/
>
> BS: Will fix both of these.

> ** 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.
>
> BS: I will add explanatory text here and for the challenge bundle of:

The allowed interval starts at the Creation Timestamp and extends for the
Lifetime of the Response Bundle.

> ** 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?
>
> BS: Not explicitly; the concept being that the BP node operated by the
ACME server would be implicitly trusted (e.g. pre-configured on the ACME
client's BP node) and would be BIB-signing its own outgoing bundles. This
is similar in concept to the ACME HTTP server having a TLS-purpose
certificate chained to a CA trusted by the ACME HTTP client. This
doesn't *prohibit
*a network from using an integrity gateway in both directions (or using any
other variety of extension blocks and exotic BP configs) but doesn't
require it.

> ** 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.
>
> BS: Agreed, and I will add a security subsection to clarify this.

> ** 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?
>
>  BS: I am adding a few paragraphs for this topic, because most of this
communication doesn't need confidentiality but it does need to have
positive access control and prevent spoofing.