Re: [TLS] New curves work and TLS

Eric Rescorla <ekr@rtfm.com> Thu, 15 October 2015 19:25 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8BA1A00E4 for <tls@ietfa.amsl.com>; Thu, 15 Oct 2015 12:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 oP1T77sI2HJA for <tls@ietfa.amsl.com>; Thu, 15 Oct 2015 12:25:38 -0700 (PDT)
Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941651A00C0 for <tls@ietf.org>; Thu, 15 Oct 2015 12:25:38 -0700 (PDT)
Received: by ykfy204 with SMTP id y204so64643303ykf.1 for <tls@ietf.org>; Thu, 15 Oct 2015 12:25:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Uxr595TLZLJYG3xreNMhhhIbFcMTeNj1CJ8y6e6lkHQ=; b=Icdsva36qXDatsVkP5pLOGERn8h4nkXZQUkNc2o4/jEPGIKpGHoxiJiJcxMQKzIpFk UJR4GKemsQ63h6X8znizeijtEmhkGF5UTNkcIlhgPPdfxaomZ/7bemT7h2OERvdlDB16 P2FYRr8ig2xJoCjrHEaoLxS0YjB0QeT+VilTQP8RPnk4f+RrMLhuslv67FmhTr/10SLE +NkKQF5VsIaV0SLr+G6pcxlEWEgbpviibiNgHpw2Mzv1UCGN+2SGvVNgxcZQ0lW2p7+I Kkc3AKNZHp3JWBFsIu7mtxQI9AFkfIWttbZS9bLONbIaBDz4xOaqGk9kkE5jJ9wGJxAy nxcA==
X-Gm-Message-State: ALoCoQmoQ95wnj90M+V1DVDetQ1bikhw1Jh/79vbf428PJTWwPnY4D8/B+VXG5Kj6poZQwlhXUzG
X-Received: by 10.13.214.195 with SMTP id y186mr7939926ywd.81.1444937137805; Thu, 15 Oct 2015 12:25:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.114.85 with HTTP; Thu, 15 Oct 2015 12:24:58 -0700 (PDT)
In-Reply-To: <201510151517.52101.davemgarrett@gmail.com>
References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> <201510151517.52101.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 15 Oct 2015 12:24:58 -0700
Message-ID: <CABcZeBMKsHkWtGxYJm16Lww49a9j314RRVuuLQYYXFg+vbRBLA@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=001a114fcea8d28ecf052229a41b
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ClUZFs8yuG677ppt6xcOEJyGbdw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New curves work and TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 15 Oct 2015 19:25:41 -0000

On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett <davemgarrett@gmail.com>;
wrote:

> On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> > Ed448ph. And keys MUST NOT be mixed between those.
> >
> > I propose the following:
> > - EdDSA uses one SignatureAlgorithm value (5?[1]).
> > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and
> >   another for Ed448/Ed448ph
> > - If there is ever EdDSA instantiation with Edwards448 curve (the same
> >   one Ed448 uses) with another KDF, it gets a new curve distinct from
> >   Ed448/Ed448ph.
> > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or
> >   value matching the prehash (but the prehash is always done once[2]).
> >   [TBD: resolve this]
>
> I've been thinking about the issue of how to handle
> SignatureAndHashAlgorithm values better. I think this time, I'd like to
> propose going the opposite way we'd normally want to move: let's consider
> enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of
> having independent values. We're moving to signature algorithms that don't
> have arbitrary hashes, so the current system isn't really ideal anymore.
>
> Current draft:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1
> (text)
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88  (full
> registry)
> ----------------------------------------
> enum {
>     none(0),
>     md5_RESERVED(1),
>     sha1(2),
>     sha224_RESERVED(3),
>     sha256(4), sha384(5), sha512(6),
>     (255)
> } HashAlgorithm;
>
> enum {
>     anonymous_RESERVED(0),
>     rsa(1),
>     dsa(2),
>     ecdsa(3),
>     rsapss(4),
>     (255)
> } SignatureAlgorithm;
>
> struct {
>     HashAlgorithm hash;
>     SignatureAlgorithm signature;
> } SignatureAndHashAlgorithm;
> ----------------------------------------
>
> Proposed replacement backwards-compatible registry:
> ----------------------------------------
> struct {
>     anonymous_RESERVED(0x0000),
>     rsa_nohash(0x0001),
>     dsa_nohash(0x0002),
>     ecdsa_nohash(0x0003),
>     rsapss_nohash(0x0004),
>     md5_RESERVED (0x0100..0x01FF),
>     rsa_sha1(0x0201),
>     dsa_sha1(0x0202),
>     ecdsa_sha1(0x0203),
>     rsapss_sha1(0x0204),
>     sha224_RESERVED (0x0300..0x03FF),
>     rsa_sha256(0x0401),
>     dsa_sha256(0x0402),
>     ecdsa_sha256(0x0403),
>     rsapss_sha256(0x0404),
>     rsa_sha384(0x0501),
>     dsa_sha384(0x0502),
>     ecdsa_sha384(0x0503),
>     rsapss_sha384(0x0504),
>     rsa_sha512(0x0601),
>     dsa_sha512(0x0602),
>     ecdsa_sha512(0x0603),
>     rsapss_sha512(0x0604),
>     (0xFFFF)
> } SignatureAndHashAlgorithm;
> ----------------------------------------
>
> New values could be assigned specific combinations as needed. This would
> also let hashes & signatures be deprecated independently easily, e.g. allow
> rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from
> the start).


I am not in favor of this change. Because we can already indicate
combinations, this
doesn't seem to add significant new value. If we need to indicate
"signature algorithm
without a hash" then a "none" hash is the simplest solution.

-Ekr