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

Matt Caswell <> Mon, 18 November 2019 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFDEA1200B5 for <>; Mon, 18 Nov 2019 14:53:28 -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 hJ-qSlFZ0vuz for <>; Mon, 18 Nov 2019 14:53:27 -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 16AE712009E for <>; Mon, 18 Nov 2019 14:53:27 -0800 (PST)
Received: from [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd] (unknown [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 13BC8E4EC1; Mon, 18 Nov 2019 22:53:25 +0000 (UTC)
To: "Salz, Rich" <>, "" <>
References: <> <>
From: Matt Caswell <>
Message-ID: <>
Date: Mon, 18 Nov 2019 22:53:24 +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: Mon, 18 Nov 2019 22:53:29 -0000

On 18/11/2019 22:38, Salz, Rich wrote:
> 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


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