Subject: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

From: Matt Caswell <[email-masked]>
Date: Mon, 18 Nov 2019 16:50:03 +0000

RFC8422 specifies the usage of Ed25519 and Ed448 in TLSv1.2. However
there is barely any mention of DTLS. There is one reference which says this:

"IANA has assigned one value from the "TLS HashAlgorithm" registry for
Intrinsic (8) with DTLS-OK set to true (Y) and this document as
reference.  This keeps compatibility with TLS 1.3."

That's in reference to the IANA TLS HashAlgorithm registry. But for the
TLS SignatureAlgorithm registry it says this:

"IANA has assigned two values in the "TLS SignatureAlgorithm" registry
for ed25519 (7) and ed448 (8) with this document as reference.  This
keeps compatibility with TLS 1.3."

This is in the paragraph before the other one, and there is no reference
to ed25519/ed448 being "ok" for DTLS, and in fact there is no mention of
DTLS anywhere else in this RFC.

However the IANA TLS SignatureAlgorithm registry lists ed25519/ed448 as
"ok" for DTLS and cites RFC8422 as a reference:

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16

Is this an error in the IANA registry? Or is this an error in the RFC?
Or is there some other RFC somewhere that specifies ed25519/ed448 usage
in DTLS?

I looked to see if there were any errata for RFC8422, but nothing looked
relevant.

Thanks

Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Nov 2019 22:38:48 +0000

Does Sesction 15 of RFC 8447 help?

---

From: Matt Caswell <[email-masked]>
Date: Mon, 18 Nov 2019 22:53:24 +0000

> Does Sesction 15 of RFC 8447 help?

Not really, no. It adds some broad statements about the applicability of
these registries, i.e. that they're only useful for DTLS1.2 and below,
and adds some reserved fields. But it offers no explanation for where
the "DTLS-OK" value of "Y" has come from for ed25519/ed448. The only
reference those values have against them is RFC 8442 and that RFC does
not say anything about DTLS-OK being "Y" for them.

My guess is either:

1) The registry is in error and they should not have Y against them

or

2) The intent behind RFC 8442 was that it should apply to DTLS but it
was missed in error.

The third possibility is that there is some other RFC that specifies
this (but if so why doesn't the "Reference" column list it).

Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Nov 2019 00:41:16 +0000

As 8422 says "DTLS-OK" and since Yoav is both an author of the RFC and one of the registry experts, I think he needs to reply here.

    was missed in error.
    
#1 is the simple fix, but it seems wrong.  #2 could *probably* be fixed with an errata, but hard to do in a way that doesn't make the changes invasive.

FWIW, as another one of the registry experts, I prefer #2.

---

From: Matt Caswell <[email-masked]>
Date: Tue, 19 Nov 2019 09:17:17 +0000

> #1 is the simple fix, but it seems wrong.  #2 could *probably* be fixed with an errata, but hard to do in a way that doesn't make the changes invasive.

Sorry, that should have been RFC 8422 above (not 8442).

Looking at 8422 it seems to me that starting from the title and all the
way through it is exclusively talking about TLS and not DTLS. So, on
reflection, I think fixing it via errata doesn't seem feasible to me.
Perhaps a new RFC could be fairly easily written to apply the changes to
DTLS too.

Either way, it seems to me that the current state of the registry
doesn't match what the RFCs state. This is quite confusing - I
discovered this issue because of a question to the OpenSSL users list
asking why EdDSA certificates could not be used in an OpenSSL DTLS
connection when the registry says that they are allowed. Therefore it
seems to me that the right answer is to correct the registry - at least
for now. Even if there is a subsequent RFC that changes it back again.

Is there a formal process for reporting registry errata? Or is it just a
case of reporting it direct to the assigned experts?

Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Nov 2019 09:20:43 +0000

Report it to IANA ([email-masked]) who will pass it to the experts.

I would suggest waiting for Yoav to comment first.  Because I promise the experts will wait for him anyway :)

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Nov 2019 20:58:44 -0800

> seems to me that the right answer is to correct the registry - at least

Quoting from RFC 6347:

   DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11].
   This document introduces a new version of DTLS, DTLS 1.2, which is
   defined as a series of deltas to TLS 1.2 [TLS12].  [...]

The presumption should be that anything defined for TLS (1.2) is also
defined for DTLS (1.2); if you look at things in any of the IANA
registries that are marked as DTLS-OK(N), you'll find that they are few
and far between, and that there is some (cryptographic) reason why they
are incompatible with DTLS usage, which can involve (e.g.) out-of-order
delivery and retransmission.  E.g., RC4 is a stream cipher and can't
handle out-of-order delivery, so TLS_ECDH_RSA_WITH_RC4_128_SHA is
DTLS-OK(N).

The two signature algorithms in question are pretty bog standard
cryptographic primitives, and only get used in the handshake anyway, so
it's pretty clear to me that hey are rightly marked as DTLS-OK(Y).

I could only find the AUTHj48 discussions in my mail archives; it's
possible that the IANA discussions happened before I was responsible AD.
If you're still uncertain after the above, we can try to dig up some
more history of where the DTLS-OK(Y) came from.

-Ben

---

From: Matt Caswell <[email-masked]>
Date: Thu, 21 Nov 2019 08:59:41 +0000

> more history of where the DTLS-OK(Y) came from.

This is ok as an answer but it means there is no traceability of entries
in the registry to RFCs that specify those entries - and that can lead
to confusion. That has happened in this case (those signature schemes
are explicitly coded as TLSv1.2 only in OpenSSL).

If you take the line that "anything specified for TLSv1.2 is implicitly
ok for DTLSv1.2 unless stated otherwise", then I at least think an RFC
should have a minimal nod towards DTLS. At least to give the message
that "yes, we have considered this in a DTLS setting and its fine". As
you state above there are exceptions, so we do need to consider this on
a case-by-case basis. In the case of RFC8422, as a minimum I would have
expected that to be in the form of a sentence saying that those entries
should have DTLS-OK against them in section 9 - especially as the
following paragraph *does* say this for the "Intrinsic" HashAlgorithm
registry entry (rather implying by omission that this doesn't hold for
ed25519/ed448).

Matt

---

From: Matt Caswell <[email-masked]>
Date: Fri, 22 Nov 2019 16:01:40 +0000

> registry entry (rather implying by omission that this doesn't hold for

Is the correct way ahead with this to raise it as an erratum on the RFC?
I am still not entirely convinced that its not just an error in the
registry. But IMO *somewhere* between those two there is an error.

Matt