Subject: Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' to Proposed Standard (draft-ietf-ace-dtls-authorize-18.txt)

From: John Mattsson <[email-masked]>
Date: Thu, 4 Nov 2021 14:08:16 +0000

Thanks to the IESG for stepping in and adding DTLS 1.3. Very much appreciated!

I think IESG should send any (D)TLS 1.2 only drafts back to the WGs from now on. A lot of SDOs and industries are working hard on updating all (D)TLS applications to work also with 1.3. The last thing the world needs is more 1.2 only standards.

I was surprised already in 2017 that the draft was 1.2 only.
https://datatracker.ietf.org/meeting/98/materials/minutes-98-ace-00

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Nov 2021 16:14:26 +0100

On 2021-11-04, at 15:08, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> I think IESG should send any (D)TLS 1.2 only drafts back to the WGs from now on. 

Since you made this comment on an approved document (which the IESG no longer gets to “send back”), I’m not sure I understand what you are trying to say, but I don’t agree with any of the possible interpretations.

> A lot of SDOs and industries are working hard on updating all (D)TLS applications to work also with 1.3. The last thing the world needs is more 1.2 only standards.

I don’t think we need to form a queue behind the completion of DTLS 1.3.
This apparently will take some more time:
https://www.rfc-editor.org/auth48/C321
2021-10-18:  Received email from Eric Rescorla that an open technical issue is ongoing.

However, we should already have been working on a -bis for the DTLS profile that also supports DTLS 1.3; I can certainly agree with that.

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Nov 2021 15:37:43 +0000

The -17 and -18 versions clearly states that it can be used with DTLS 1.3. The GitHub version, which I assume will be the basis for the RFC also explains the psk identity differences between 1.2 and 1.3, which is great. I don’t think there is a need to do anything more.

Regarding DTLS 1.3 support, I don’t think there is any need for a -bis version, DTLS 1.3 is to my understanding already supported by the current document thanks to IESG.

John

From: Carsten Bormann <[email-masked]>
Date: Thursday, 4 November 2021 at 16:14
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' to Proposed Standard (draft-ietf-ace-dtls-authorize-18.txt)

I don’t think we need to form a queue behind the completion of DTLS 1.3.
This apparently will take some more time:
https://protect2.fireeye.com/v1/url?k=8ed7d76d-d14cee6d-8ed797f6-86fc6812c361-b378f81d3777bcda&q=1&e=5985dba9-7ace-4fe4-9ace-256b8615b396&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2FC321
2021-10-18:  Received email from Eric Rescorla that an open technical issue is ongoing.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Nov 2021 16:55:39 +0100

Hi John,

sorry, didn’t have that context.

> Regarding DTLS 1.3 support, I don’t think there is any need for a -bis version, DTLS 1.3 is to my understanding already supported by the current document thanks to IESG.

That assumes that DTLS 1.3 is finished with its publication.
This is a lively ecosystem, so I’d expect they will throw some goodies over the fence that we’ll want to use.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Nov 2021 13:55:56 -0400

We are really some years away from *DTLS* from being ubiquitously available
in libraries.   Even for those that have some of it, it doesn't all work that
well.  And it might not be available in FIPS certified libraries yet.

In RFC8995, we wrote (section 5.1) after IESG review:

   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
   REQUIRED on the pledge side.

Encourage 1.3.  Tolerate 1.2.
This does cause some policy bifuration because of the different ways in which
ciphers are named/negotiated, but that should not be a problem in practice.
The CCM-8/MTI for CoAPS is really the bigger problem that we need to resolve.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-