Subject: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt

From: [email-masked]
Date: Wed, 22 Sep 2021 21:19:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment WG of the IETF.

        Title           : Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
        Author          : Brian Sipos
	Filename        : draft-ietf-acme-dtnnodeid-05.txt
	Pages           : 29
	Date            : 2021-09-22

Abstract:
   This document specifies an extension to the Automated Certificate
   Management Environment (ACME) protocol which allows an ACME server to
   validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
   client.  The DTN Node ID is encoded as a certificate Subject
   Alternative Name (SAN) of type otherName with a name form of
   "bundleEID" and as an ACME Identifier type "bundleEID".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Sipos <[email-masked]>
Date: Sun, 26 Sep 2021 09:23:45 -0400

All,
This latest update to the DTN Node ID validation draft should resolve all
of the AD comments *except* for this document updating a document from a
different WG. The discrepancy in BPv7 (not) using admin record type IANA
registry can be pulled out of this ACME document and made into its own
separate DTN WG draft. But that would need to be a normative reference of
this document and I didn't want to make big structural changes with the
other edits.

Part of this update is a change in the related DTN/BP PKIX profile (from
TCPCLv4) to avoid using SAN URI and instead use a SAN otherName form
specific to bundle EID content. The logic on the ACME side is otherwise the
same, just with a different identifier name and its associated PKIX claim
source. I still see a couple of vestigial mentions of "URI" that need to be
replaced for consistency.

Please let me know if there are any other issues to discuss before the next
interim,
Brian S.

On Thu, Sep 23, 2021 at 12:19 AM <[email-masked]> wrote:

>         Title           : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
>         Author          : Brian Sipos
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Aaron Gable <[email-masked]>
Date: Wed, 29 Sep 2021 14:50:55 -0700

A couple comments/questions from my recent read-through.

- In Section 3, it says "the validation procedure is successful only if all
responses are successful". This language is included because the draft
explicitly accounts for multi-perspective validation, with each perspective
using a different `token-bundle` value. Speaking as a Let's Encrypt
engineer: our research into[1] and practical experience with[2][3]
multi-perspective validation for current ACME challenge types is that
requiring *all* validations to succeed is both not necessary for security
and is actively harmful for reliability. Let's Encrypt's current policy is
twofold: First, the validation from within the audited, secure data center
perspective must succeed, as required by the Baseline Requirements; Second,
no more than one of the remote perspectives can fail validation. This
allows the CA to take advantage of multiple perspectives, without creating
undue latency or reliability problems. Obviously, these bundleEID
certificates would not be issued by CAs subject to the CA/BF BRs, so the
situation is slightly different. But unless there is a very compelling
reason to do so that I'm not aware of, I would caution against requiring
that every perspective succeed in this specification, and instead leave
that up to server policy.

[1]
https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
[2]
https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee
[2] https://letsencrypt.org/2020/02/19/multi-perspective-validation.html

- It is not clear to me why the `token-chal` value is included in both the
ACME Server's `dtn-nodeid-01` Challenge resource and in the BP Agent's
Challenge Bundle administrative record content. The overview of the client
procedure in Section 3 makes it seem like the ACME Client should be
communicating the `token-chal` to its BP Agent, so that it can be used to
fulfil the challenge. But Section 3.4 says that the response's `token-chal`
should be copied from the Request bundle. The inclusion of the `token-chal`
in both places feels redundant. If it is not, and there is good reason for
its inclusion in both places, then I believe the language should be updated
to make that reasoning clear.

- Finally, Section 3.4.1 says that the Response Bundle must be received in
the interval which "starts at the Creation Timestamp and extends for the
Lifetime of the Response Bundle". Why is this the lifetime of the Response
Bundle, as opposed to the lifetime of the Challenge Bundle? A server should
only accept responses that arrive within the window that it defines;
although the draft says that the client's Response Bundle SHALL have a
lifetime which is contained within the Challenge Bundle's lifetime, a
malicious client could ignore that constraint and generate bundles with
lifetimes far into the future and a strictly-implemented server would be
obligated to accept them.

Thanks,
Aaron

On Sun, Sep 26, 2021 at 6:24 AM Brian Sipos <[email-masked]>
wrote:

> Please let me know if there are any other issues to discuss before the
> next interim,
> Brian S.
>

---

From: Brian Sipos <[email-masked]>
Date: Thu, 30 Sep 2021 18:28:39 -0400

Aaron,
These are all good points to notice. My responses are inline below with the
prefix "BS1".

On Wed, Sep 29, 2021 at 5:51 PM Aaron Gable <[email-masked]> wrote:

> - In Section 3, it says "the validation procedure is successful only if
> all responses are successful". This language is included because the draft
> BS1: Yes, the current required behavior was not driven by anything but a
simple, and naive, logic. I agree that making it a matter of CA policy
would be better, and then I can add that "The RECOMMENDED policy is ..." to
agree with what you have described: one primary perspective succeeds and at
least all-but-one other perspectives succeed.

> BS1: This is to handle a basic property that BP bundles are necessarily
independent units, unidirectional, and (currently) have no "conversation"
or "flow" associations at the BP layer. Any associations between bundles
must be made at the application layer above, so in fact tuple (token-chal,
token-bundle) is the *only* way for an ACME Server to correlate the two
bundles.
This is the same way that RFC8823 uses to correlate the two emails. Because
email and bundles both have similar logical patterns of transport, this
Node ID validation is intended to have the same structure and security
properties as the email validation.

> BS1: I agree that ideally these would indicate the same end time, but the
ACME server should trust only its own originated data, i.e. from the
challenge bundle. This will be reworded with a clarifying statement about
why.