Subject: [dtn] FW: [Acme] WGLC for ACME DTN Node ID

From: Brian Sipos <[email-masked]>
Date: Fri, 9 Apr 2021 21:30:29 +0000

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

---

From: Brian Sipos <[email-masked]>
Date: Thu, 15 Apr 2021 18:31:51 +0000

All,
One procedural complication I see is that because BPv7 didn't update the Bundle Administrative Record Types sub-registry table [4] to include a "Bundle Protocol Version" or similar column, it will need to be done by the next spec which adds a new admin record type. Record type 1 is shared between BP 6,7 but type 2 is exclusive to 6.

I'm not sure exactly how this will need to be phrased from the perspective of this table-updating document.

[4] https://www.iana.org/assignments/bundle/bundle.xhtml#admin-record-types

________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Friday, April 9, 2021 17:30
To: [email-masked] <[email-masked]>
Subject: [dtn] FW: [Acme] WGLC for ACME DTN Node ID

All,

[1] https://mailarchive.ietf.org/arch/msg/acme/ncn3LR_i8mPcAKx3qt33FgYuoK4/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Facme%2Fncn3LR_i8mPcAKx3qt33FgYuoK4%2F&data=04%7C01%7CBSipos%40rkf-eng.com%7C45866daaec1d4b2b522a08d8fb9ebd59%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637536006513579548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ck8SLRslkaZXGH%2B%2Fv0NlzdXdpmLFfUhwtSs5sYga6yk%3D&reserved=0>
[2] https://tools.ietf.org/html/draft-ietf-acme-email-smime-13<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-email-smime-13&data=04%7C01%7CBSipos%40rkf-eng.com%7C45866daaec1d4b2b522a08d8fb9ebd59%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637536006513589540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zCSzSUI%2FyaVnpAkr7jKrD82jXH4ToLAar2UGB3Fttl8%3D&reserved=0>
[3] https://www.rfc-editor.org/rfc/rfc6376.html<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&data=04%7C01%7CBSipos%40rkf-eng.com%7C45866daaec1d4b2b522a08d8fb9ebd59%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637536006513589540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6aZo1x9rXwMfxUU8aTiqYfHlw6tn%2FTx75oUfvVwCLMQ%3D&reserved=0>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 20 Apr 2021 22:34:10 +0000

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 .

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.

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.

Scott

From: dtn <[email-masked]> On Behalf Of Brian Sipos
Sent: Friday, April 9, 2021 2:30 PM
To: [email-masked]
Subject: [EXTERNAL] [dtn] FW: [Acme] WGLC for ACME DTN Node ID

All,

[1] https://mailarchive.ietf.org/arch/msg/acme/ncn3LR_i8mPcAKx3qt33FgYuoK4/<https://urldefense.us/v3/__https:/mailarchive.ietf.org/arch/msg/acme/ncn3LR_i8mPcAKx3qt33FgYuoK4/__;!!PvBDto6Hs4WbVuu7!ZcEiIN8ePKo7_Ho0XtA-OwD7_DLXc3MHwTKyC308sqWmyS4d9-5yVZuZqBV9C6RK06OO5aFWsug$>
[2] https://tools.ietf.org/html/draft-ietf-acme-email-smime-13<https://urldefense.us/v3/__https:/tools.ietf.org/html/draft-ietf-acme-email-smime-13__;!!PvBDto6Hs4WbVuu7!ZcEiIN8ePKo7_Ho0XtA-OwD7_DLXc3MHwTKyC308sqWmyS4d9-5yVZuZqBV9C6RK06OOqxrI6AE$>
[3] https://www.rfc-editor.org/rfc/rfc6376.html<https://urldefense.us/v3/__https:/www.rfc-editor.org/rfc/rfc6376.html__;!!PvBDto6Hs4WbVuu7!ZcEiIN8ePKo7_Ho0XtA-OwD7_DLXc3MHwTKyC308sqWmyS4d9-5yVZuZqBV9C6RK06OO2Uj2jq4$>

---

From: Brian Sipos <[email-masked]>
Date: Thu, 22 Apr 2021 13:33:10 +0000

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.

> 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.
>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 22 Apr 2021 15:38:50 +0000

I think it does make sense.  Computing the total required time may be non-trivial, especially if bundles exchanged between the client and server have to be forwarded by one or more additional BP agents, but the approach seems right.

Scott

-----Original Message-----
From: Brian Sipos <[email-masked]> 
Sent: Thursday, April 22, 2021 6:33 AM
To: [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>
Subject: [EXTERNAL] Re: [Acme] WGLC for ACME DTN Node ID

...

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.