Is ED25519 on DTLS supported?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Is ED25519 on DTLS supported?

Rafael Ferrer
It's DTLS-OK according to IANA.


I tested ED25519 certificates on TLS 1.2 and it worked fine.

openssl s_server -port 4321 -cert server-cert.pem -key server-key.pem -CAfile client-cert.pem -tls1_2 -sigalgs ed25519
openssl s_client -bind localhost:1234 -connect localhost:4321 -cert client-cert.pem -key client-key.pem -CAfile server-cert.pem -tls1_2 -sigalgs ed25519

But I get a "no shared cipher" error (on the server) if I just replace -tls1_2 with -dtls1_2 on those two commands.


The certs and keys are self-signed for both the server and client and where generated by this command.

openssl req -x509 -newkey ed25519 -subj "/CN=localhost" -nodes -addext keyUsage=digitalSignature -keyout key.pem -out cert.pem

Reply | Threaded
Open this post in threaded view
|

Re: Is ED25519 on DTLS supported?

Matt Caswell-2


On 17/11/2019 01:43, Rafael Ferrer wrote:

> It's DTLS-OK according to IANA.
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16
>
>
> I tested ED25519 certificates on TLS 1.2 and it worked fine.
>
> openssl s_server -port 4321 -cert server-cert.pem -key server-key.pem
> -CAfile client-cert.pem -tls1_2 -sigalgs ed25519
> openssl s_client -bind localhost:1234 -connect localhost:4321 -cert
> client-cert.pem -key client-key.pem -CAfile server-cert.pem -tls1_2
> -sigalgs ed25519
>
> But I get a "no shared cipher" error (on the server) if I just replace
> -tls1_2 with -dtls1_2 on those two commands.
>
>
> The certs and keys are self-signed for both the server and client and
> where generated by this command.
>
> openssl req -x509 -newkey ed25519 -subj "/CN=localhost" -nodes -addext
> keyUsage=digitalSignature -keyout key.pem -out cert.pem
>


This is a really good question. Currently Ed25519 certificates are not
supported in DTLS. The function ssl_set_masks() in ssl_lib.c has this code:

    /* Allow Ed25519 for TLS 1.2 if peer supports it */
    if (!(mask_a & SSL_aECDSA) && ssl_has_cert(s, SSL_PKEY_ED25519)
            && pvalid[SSL_PKEY_ED25519] & CERT_PKEY_EXPLICIT_SIGN
            && TLS1_get_version(s) == TLS1_2_VERSION)
            mask_a |= SSL_aECDSA;

Note, this explicitly checks for TLSv1.2 and only allows ED25519 if it
is true. There is no equivalent code for DTLSv1.2.

Technically getting it to support DTLSv1.2 is easy. We just amend the
above line to additionally check for DTLSv1.2 and it should work. The
question is, is that correct? EdDSA support for TLSv1.2 was specified in
RFC8422. That RFC only has one mention of DTLS here:

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

So, I'm slightly perplexed as to why the IANA registry says something
different to this (i.e. DTLS is "ok" for ed25519/ed448). 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.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: Is ED25519 on DTLS supported?

Matt Caswell-2


On 18/11/2019 16:42, Matt Caswell wrote:

>
>
> On 17/11/2019 01:43, Rafael Ferrer wrote:
>> It's DTLS-OK according to IANA.
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16
>>
>>
>> I tested ED25519 certificates on TLS 1.2 and it worked fine.
>>
>> openssl s_server -port 4321 -cert server-cert.pem -key server-key.pem
>> -CAfile client-cert.pem -tls1_2 -sigalgs ed25519
>> openssl s_client -bind localhost:1234 -connect localhost:4321 -cert
>> client-cert.pem -key client-key.pem -CAfile server-cert.pem -tls1_2
>> -sigalgs ed25519
>>
>> But I get a "no shared cipher" error (on the server) if I just replace
>> -tls1_2 with -dtls1_2 on those two commands.
>>
>>
>> The certs and keys are self-signed for both the server and client and
>> where generated by this command.
>>
>> openssl req -x509 -newkey ed25519 -subj "/CN=localhost" -nodes -addext
>> keyUsage=digitalSignature -keyout key.pem -out cert.pem
>>
>
>
> This is a really good question. Currently Ed25519 certificates are not
> supported in DTLS. The function ssl_set_masks() in ssl_lib.c has this code:
>
>     /* Allow Ed25519 for TLS 1.2 if peer supports it */
>     if (!(mask_a & SSL_aECDSA) && ssl_has_cert(s, SSL_PKEY_ED25519)
>             && pvalid[SSL_PKEY_ED25519] & CERT_PKEY_EXPLICIT_SIGN
>             && TLS1_get_version(s) == TLS1_2_VERSION)
>             mask_a |= SSL_aECDSA;
>
> Note, this explicitly checks for TLSv1.2 and only allows ED25519 if it
> is true. There is no equivalent code for DTLSv1.2.
>
> Technically getting it to support DTLSv1.2 is easy. We just amend the
> above line to additionally check for DTLSv1.2 and it should work. The
> question is, is that correct? EdDSA support for TLSv1.2 was specified in
> RFC8422. That RFC only has one mention of DTLS here:
>
> "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 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.
>
> So, I'm slightly perplexed as to why the IANA registry says something
> different to this (i.e. DTLS is "ok" for ed25519/ed448). 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.

Note, I just asked about this on the TLS WG list.

Matt

Reply | Threaded
Open this post in threaded view
|

Re: Is ED25519 on DTLS supported?

Rafael Ferrer
Thanks, I'll read up on your discussion there.

My original use for this is to share the same certificate and key on a
process that has both a TLS and DTLS connection. I went with just making
the DTLS derive a PSK from the keying material of the TLS.