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
- [TLS] New curves work and TLS Ilari Liusvaara
- Re: [TLS] New curves work and TLS Dave Garrett
- Re: [TLS] New curves work and TLS Eric Rescorla
- Re: [TLS] New curves work and TLS Ilari Liusvaara
- Re: [TLS] New curves work and TLS Sean Turner
- Re: [TLS] New curves work and TLS Ilari Liusvaara