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

From: Aaron Gable <[email-masked]>
Date: Mon, 4 Oct 2021 12:05:05 -0700

Brian,

Fantastic, thank you for the responses! One further comment inline.

On Thu, Sep 30, 2021 at 3:28 PM Brian Sipos <[email-masked]>
wrote:

> 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.
>

RFC8823 sends the two tokens via separate mechanisms: token-part1
(corresponding to token-bundle) is sent only in the email, and token-part2
(corresponding to token-chall) is provided only via the Challenge object
over HTTPS to the ACME client. This draft differs, in that both token-chall
*and* token-bundle are provided in the Challenge Bundle. I believe that an
ACME Server, rather than its BP Agent, should be responsible for verifying
that the Response Bundle is correct, so there is no need for the Server's
BP Agent to ever be aware of token-chall at all, just as in RFC8823 there
is no reason for the Server's email agent to ever be aware of the
token-part2 that is part of the Challenge object.

Thanks,
Aaron

---

From: Brian Sipos <[email-masked]>
Date: Mon, 4 Oct 2021 22:16:42 -0400

Aaron,
Yes, this is intentional and it's due to a slight difference in the
mechanics between the two mechanisms.
While the RFC 8823 mechanism can generate a unique "from" email address for
each challenge (e.g. the document example "
[email-masked]") that the client can use to
filter-in valid challenges, the Bundle protocol has no such controllable
uniqueness at the BP layer (i.e the Primary Block).  In RFC 8823 the "from"
address can be used by an ACME-aware mail client to ignore unauthorized
requests. While in the proposed Node ID validation the ACME server's Source
Node ID is the same for all challenges, and only the "token-chal" is
distinct for the authorized challenge. The ACME client's BP agent can use
this to filter-in (and respond to) only authorized challenges.

This does bring up the point that multi-perspective validation would have
different challenge bundle Source Node ID for each perspective, so the
current logic of defining a single "source" for each challenge limits the
multi-perspective use to routing from multiple forwarders but all from the
same source (and thus the response bundle going to the same destination).
If the "token-chal" is assumed to be globally unique, then the client
really doesn't need to know what ACME servers are making the challenges.