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 <[email protected]> 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. <[email protected]> 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 <[email protected]> *On Behalf Of *Deb Cooley *Sent:* Tuesday, May 24, 2022 7:39 AM *To:* IETF ACME <[email protected]>; Brian Sipos <[email protected]> *Cc:* Roman Danyliw <[email protected]>; Dorothy E Cooley < [email protected]> *Subject:* [EXT] Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt *APL external email warning: *Verify sender [email protected] 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> *On Behalf Of *Brian Sipos *Sent:* Wednesday, March 2, 2022 11:27 PM *To:* IETF ACME <[email protected]> *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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
