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

[Benjamin Kaduk <[e-mail]>]

On Tue, Nov 19, 2019 at 09:17:17AM +0000, Matt Caswell wrote:
> 
> 
> On 19/11/2019 00:41, Salz, Rich wrote:
> > 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.
> > 
> >>    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.
> >     
> > #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

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