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 <aa...@letsencrypt.org> wrote: > 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 > > 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. > - 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. > > 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. > - 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. > > 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. > Thanks, > Aaron > > On Sun, Sep 26, 2021 at 6:24 AM Brian Sipos <brian.sipos+i...@gmail.com> > wrote: > >> 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 <internet-dra...@ietf.org> wrote: >> >>> >>> 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/ >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
