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

Matt Caswell <> Thu, 21 November 2019 08:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11F57120086 for <>; Thu, 21 Nov 2019 00:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Y_eHjgBItan for <>; Thu, 21 Nov 2019 00:59:44 -0800 (PST)
Received: from ( [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1300F12083E for <>; Thu, 21 Nov 2019 00:59:44 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C5AD3E4E88; Thu, 21 Nov 2019 08:59:41 +0000 (UTC)
To: Benjamin Kaduk <>
Cc: "Salz, Rich" <>, "" <>
References: <> <> <> <> <> <>
From: Matt Caswell <>
Message-ID: <>
Date: Thu, 21 Nov 2019 08:59:41 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Nov 2019 08:59:46 -0000

On 20/11/2019 04:58, Benjamin Kaduk wrote:
> 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
> 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.

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