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

[Stephen Farrell <[e-mail]>]

Hi Brian,

On 08/09/2022 02:58, Brian Sipos wrote:
> 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 paragraph on that added in PR#5 looks good to me.

> 
> The rationale for Section 3.5 is really to maintain parity with the
> existing ACME validation methods

Understood. But I'm not at all sure we know (now) what to say
to try achieve such parity, so this mechanism could lead down
the wrong path maybe, and we won't know 'till the experiments
are done.

For example, for many DTNs, say where there's only one g/w
that connects the challenged region(s) to the Internet (and
with ACME server on the Internet), emitting bundles from
different Internet-connected sources would not affect the
capabilities of an attacker who has control of that one g/w.
(Or of anyone close enough to the challenged side of the
g/w to be the next-hop any time they wanted to be.)

That's very different from the case with e.g. LE and DNS,
where we do know a lot more about IP routing and DNS name
resolution and how that affects the capability of on-path
attackers.

So, as written, IMO that section is premature. If you were
to recast it as jut being a thing to try out as part of the
experiment then it'd be fine I think.

Lastly - a random thought - I wonder if bundle status reports
would be the way to try provide the kind of parity you're
after here? I could imagine that an ACME server might be more
satisfied if it were able to accumulate (BIB-protected?)
reports related to the the bundles it emits for challenges
(whether from different sources or not). There'd be a bunch
of things to figure out there, but ISTM that might be a
better approach (or maybe it'd not work;-)

Cheers,
S.


> 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 <[e-mail]>
> 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 <[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
>>
>