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

Matt Caswell <matt@openssl.org> Tue, 19 November 2019 09:17 UTC

Return-Path: <matt@openssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA212081F for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 01:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8XK0P5q6Tn5 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 01:17:23 -0800 (PST)
Received: from mta.openssl.org (xmpp.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BE11200C1 for <tls@ietf.org>; Tue, 19 Nov 2019 01:17:22 -0800 (PST)
Received: from [IPv6:2a00:23c6:2d80:b900:91c2:778c:9546:84af] (unknown [IPv6:2a00:23c6:2d80:b900:91c2:778c:9546:84af]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id C978CE4E44; Tue, 19 Nov 2019 09:17:19 +0000 (UTC)
To: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
References: <fbd7b2cc-5cfc-3b30-270f-2ae312daa0d6@openssl.org> <F810173C-C693-4A4E-8450-2FE4A9490CAE@akamai.com> <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com>
From: Matt Caswell <matt@openssl.org>
Message-ID: <a5821e1d-623d-5903-3820-8a6a76eee318@openssl.org>
Date: Tue, 19 Nov 2019 09:17:17 +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: <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6ETXZ0Jt7XL3Ci8FQOXYehbDY38>
Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 09:17:25 -0000


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
for now. Even if there is a subsequent RFC that changes it back again.

Is there a formal process for reporting registry errata? Or is it just a
case of reporting it direct to the assigned experts?

Matt