Stephen, All of your interpretations look correct to me; thank you for this insightful review!
I can add a paragraph to Section 1.1 "Scope" explaining what the experiment actually is and what it is not. I agree that the ACME validation is the well-understood portion and the utility of the mechanism is the actual experiment. The rationale for Section 3.5 is really to maintain parity with the existing ACME validation methods and to explain to implementations what assumptions to avoid (e.g., there's no longer a prior known source endpoint for the Challenge Bundle, keep responding until the client tells you to stop). Even though this is getting into more complex scenarios than the basic experiment of usefulness, I would like to keep the guidance in there for consistency of logic if someone does want to use multi-perspective. The whole thing is conditioned on "When required by policy ..." so it's really all optional. I am going to track proposed changes as part of a github ticket [1] and, if you don't mind, would like to hash out any more details in that ticket and an eventual pull request. Thanks, Brian S. [1] https://github.com/BrianSipos/acme-dtnnodeid/issues/4 On Sat, Sep 3, 2022 at 4:38 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > Someone asked me to look at this draft, so I did:-) > > On 18/08/2022 11:13, Deb Cooley wrote: > > A reminder: we need a few more eyes on this draft to move it forward. > > Overall, I think the draft is ready for experiments on which > nothing much (yet) depends, but not ready for deployments > that do need some predictable forms of security guarantee and > I don't think that distinction is clear enough in the draft > as of now. (Or, I missed it:-) > > The draft does aim to become an experimental RFC, which is > good, but I think would benefit from some text saying that > the practical security benefits from the mechanism described > here is most of the experiment. (IOW, the experiment here is > mainly about the security resulting from use of this protocol > and not experimentation as to whether this protocol will > otherwise work or not.) > > A few brief reasons for the above: > > - The emergent security properties of DTN naming and routing > schemes are mostly unknowns if we compare those against what > we know of security based on DNS and BGP (or email). > - DTN routing is far likelier to involve nodes that broadcast > or multicast or use spray-and-wait so there will be notably > more on-path nodes who could cheat, not all of which will be > "well known" (e.g. some passing data mule). > - Last I know of, (which is a while ago) BIB deployment was > still notional. That may have changed in some DTNs but I'm > also unaware that DTN security mechanisms like the BIB are > being used to secure bundles between independent DTNs. > > A not-quite-nit on the text itself: section 3.5 seems odd. > I'm not sure for what DTN topologies this might make sense > as an added security mechanism, but I'd not be surprised > if it provided no added benefit, if the ACME server were in > a well-connected region that has basically one gateway to > each DTN that's less well-connected. I don't know if the > ACME or DTN WGs considered that though, maybe they did, but > I'd probably delete that section as figuring out whether > such mechanisms add value for DTNs as they do for the DNS > is part of the experiment I'd guess and so it'd be a bit > soon to include such recommendations now. > > Cheers, > S. > > > > > Deb (and Yoav) > > > > On Thu, Jul 28, 2022 at 8:19 PM Deb Cooley <debcool...@gmail.com> wrote: > > > >> Dear ACME, > >> > >> We need to get some eyes on this draft - draft-ietf-acme-dtnnodeid. If > >> you have time, please take a look and let us know whether you think it > is > >> ready (or make comments). We are hoping to get this draft finished! > >> > >> Deb Cooley > >> > >> On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J. <brian.si...@jhuapl.edu > > > >> wrote: > >> > >>> All, > >>> > >>> I haven’t seen any reviews of the last draft version -09. I hope that > the > >>> closer alignment with RFC 8823 makes its understanding and analysis > easier. > >>> > >>> > >>> > >>> *From:* Acme <acme-boun...@ietf.org> *On Behalf Of *Deb Cooley > >>> *Sent:* Tuesday, May 24, 2022 7:39 AM > >>> *To:* IETF ACME <acme@ietf.org>; Brian Sipos < > brian.sipos+i...@gmail.com> > >>> *Cc:* Roman Danyliw <r...@cert.org>; Dorothy E Cooley < > >>> deco...@radium.ncsc.mil> > >>> *Subject:* [EXT] Re: [Acme] I-D Action: > draft-ietf-acme-dtnnodeid-09.txt > >>> > >>> > >>> > >>> *APL external email warning: *Verify sender acme-boun...@ietf.org > before > >>> clicking links or attachments > >>> > >>> > >>> > >>> Did we ever get reviews on the updated draft? If not, can we get some > >>> (or revive the) volunteers? > >>> > >>> > >>> > >>> Deb Cooley > >>> > >>> > >>> > >>> On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley <debcool...@gmail.com> > wrote: > >>> > >>> It is on the agenda. We will ask for volunteers to review. > >>> > >>> > >>> > >>> Deb > >>> > >>> > >>> > >>> On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw <r...@cert.org> wrote: > >>> > >>> Hi! > >>> > >>> > >>> > >>> We’re past IETF LC in terms of document processing and -08 and -09 > appear > >>> to have changed protocol behavior. Since there hasn’t been any > discussion > >>> about this on the mailing list yet, I’d like to ask the WG to review > these > >>> changes ( > >>> > https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09 > ). > >>> Please raise any objections by Friday April 1. > >>> > >>> > >>> > >>> Helpfully, this document is on the ACME meeting agenda tomorrow at IETF > >>> 113. > >>> > >>> > >>> > >>> Regards, > >>> > >>> Roman > >>> > >>> > >>> > >>> *From:* Acme <acme-boun...@ietf.org> *On Behalf Of *Brian Sipos > >>> *Sent:* Wednesday, March 2, 2022 11:27 PM > >>> *To:* IETF ACME <acme@ietf.org> > >>> *Subject:* Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt > >>> > >>> > >>> > >>> All, > >>> > >>> I have posted an update to the Node ID Validation document which > updates > >>> references to now-published DTN RFCs (yay!) and adds algorithm agility > for > >>> the Key Authorization Digest to avoid the validation method being > stuck on > >>> SHA-256. It does add a publication dependency on the COSE hash > document, > >>> but that is in AUTH48 (though it's been stuck in that state for some > time > >>> now). > >>> > >>> Comments are welcome and can be discussed at the next IETF. > >>> > >>> Brian S. > >>> > >>> > >>> > >>> On Wed, Mar 2, 2022 at 7:35 PM <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-09.txt > >>> Pages : 31 > >>> Date : 2022-03-02 > >>> > >>> 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-09.html > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09 > >>> > >>> > >>> Internet-Drafts are also available by rsync at rsync.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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
