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

Benjamin Kaduk <bkaduk@akamai.com> Wed, 20 November 2019 04:58 UTC

Return-Path: <bkaduk@akamai.com>
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 A6DCF12011E for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 20:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 Cz7r12xkU2n3 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 20:58:48 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB87C12004F for <tls@ietf.org>; Tue, 19 Nov 2019 20:58:48 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAK4vnsd032115; Wed, 20 Nov 2019 04:58:47 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=2XLsIam7uvLaR5FAz+Q6UU58XrSFl9i/7FOUhIDVLRw=; b=FzeV5Y42iE8IRyppYgQrXb/b7olzbQgsN7FjR47dDWGeb4i5cIjHKX6311I9jWrY2hFz K/BoMGk9akI1x5dsi8YBRl/3w+9CYfHxVHQTkW/6b0Lazt6CBm5I2msC1ZNWt28mbagS SWQOyANNATnDeJ48YMgYZwnEJ5Okrp/x6KWFNXrAlBbBrYG0SlQ+F2BRezX8hDvMWAem 71UNO7358QGJNxMoxJf3QEkESRt4o+HvjxxhXd4/kTdT9MMhN2QYCVMveQnoTkJEnHSg eEeh4v+F6jt9SvNd8GDx5VNZz0h5gs/D/3L1IWDVIfF7ibA6/y002T8SxG8l3lTEP0qx 7Q==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31r02d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 04:58:47 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAK4lJol023775; Tue, 19 Nov 2019 23:58:46 -0500
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2wadb3nbxw-1; Tue, 19 Nov 2019 23:58:46 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 1E5722006A; Wed, 20 Nov 2019 04:58:46 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1iXI4i-0001YE-K6; Tue, 19 Nov 2019 20:58:44 -0800
Date: Tue, 19 Nov 2019 20:58:44 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Matt Caswell <matt@openssl.org>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20191120045843.GU20609@akamai.com>
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> <a5821e1d-623d-5903-3820-8a6a76eee318@openssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a5821e1d-623d-5903-3820-8a6a76eee318@openssl.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=879 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200043
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_08:2019-11-15,2019-11-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=890 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200044
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JE1fJnVuNDhTmmXryl_CoxT1I88>
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: Wed, 20 Nov 2019 04:58:51 -0000

On Tue, Nov 19, 2019 at 09:17:17AM +0000, Matt Caswell wrote:
> 
> 
> 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

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
DTLS-OK(N).

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.

-Ben