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

Matt Caswell <> Fri, 22 November 2019 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D5FC1208C8 for <>; Fri, 22 Nov 2019 08:01:47 -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 Vu5r71bF00Ip for <>; Fri, 22 Nov 2019 08:01:45 -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 0D938120018 for <>; Fri, 22 Nov 2019 08:01: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 4E684E4ECC for <>; Fri, 22 Nov 2019 16:01:41 +0000 (UTC)
References: <> <> <> <> <> <> <>
From: Matt Caswell <>
Message-ID: <>
Date: Fri, 22 Nov 2019 16:01:40 +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: Fri, 22 Nov 2019 16:01:47 -0000

On 21/11/2019 08:59, Matt Caswell wrote:
> 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).

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.