Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt

[Stephen Farrell <[e-mail]>]

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