Re: [dtn] [Acme] WGLC for ACME DTN Node ID

[Brian Sipos <[e-mail]>]

Scott,
Thanks for this feedback.

On Tue, 2021-04-20 at 22:34 +0000, Burleigh, Scott C (US 312B) wrote:
> Thanks, Brian.  For what they’re worth, a couple of comments on this draft:
>  
> I agree that the BP Node ID is a reasonable claim to validate via ACME, at
> least over the Internet.  In the most general case I am skeptical about using
> the ACME workflow on a delay-tolerant network, as client/server conversations
> may be incompatible with the potentially lengthy round trips of DTN
> communications.  One possible solution, given reliable contact plans, might be
> the use of bundle delivery time estimation methods to compute RTTs per section
> 3.2 .
>  
The good news about ACME generally is that it is not timing sensitive and
doesn't make assumptions about the promptness of challenge results. Each
challenge type can have time-based and timeout behavior, but the
order/authorization/challenge workflow doesn't have any constraint on how long
any step can take and it's all event driven (the ACME client controls most of
the workflow). The current draft-ietf-acme-dtnnodeid-02 document does allow a
client to hint to the ACME server how long of an RTT to expect, so this protocol
should not break even for significantly long RTTs.

But I also agree that this is more of an internet-side protocol and more focused
on cross-domain authentication than intra-domain. Presumably if you had control
of all nodes (with their naming) *and* the CA you would just issue certificates
directly.

> A minor point: the last paragraph of 1.1 observes that the Node ID is used
> both for routing bundles among nodes and also for multiplexing services within
> a single node.  This is true of BP endpoint IDs, but not of Node IDs – aside
> from the dispatching of administrative records as noted later in that
> paragraph.
>  
Yes, I will correct this. There was some churn in this section but now the
document deals only with Node IDs and never EIDs generally.

> The value of Lifetime in the Validation Response Bundle would appear to be
> sensitive to misalignment between the system clocks of the server and client
> nodes.  A note to this effect might be helpful.
>  
You are correct that the bundle lifetime logic does assume clock
synchronization; I will add a comment about this and about how the ACME client's
node takes into account a Bundle Age extension.

For a request-response type of protocol like this, does it make sense to use the
bundle lifetime logic that is here now? The total required time encoded as the
request bundle's lifetime and then the response bundle encoding the remaining
time.

> Scott
>  
> From: dtn <[e-mail]> On Behalf Of Brian Sipos
> Sent: Friday, April 9, 2021 2:30 PM
> To: [e-mail]
> Subject: [EXTERNAL] [dtn] FW: [Acme] WGLC for ACME DTN Node ID
>  
> All,
> The ACME WG has begun last call on the draft DTN Node ID validation document
> [1], which proposes to add a BPv7 Administrative Record type to be able to
> validate ownership of a Node ID within a DTN. The ACME WG is reviewing this
> document from the ACME perspective, but it would be good to also review from
> DTN perspective.
>  
> The validation workflow is nearly identical to that email validation [2],
> which also relies on email routing and security (which itself relies on email-
> domain and DNS security) to provide assurance that the email is routed to a
> proper destination. I don't know, at this point, if there is any similar
> mechanism to DKIM [3] but making a stronger requirement about BPSec signing of
> the challenge and response bundle may be helpful; requiring a BIB sourced by
> either the ACME server or a trusted router.
>  
> [1] https://mailarchive.ietf.org/arch/msg/acme/ncn3LR_i8mPcAKx3qt33FgYuoK4/
> [2] https://tools.ietf.org/html/draft-ietf-acme-email-smime-13
> [3] https://www.rfc-editor.org/rfc/rfc6376.html
>