Re: [TLS] Simplifying signature algorithm negotiation
David Benjamin <davidben@chromium.org> Sat, 16 January 2016 01:10 UTC
Return-Path: <davidben@google.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 D5C8D1B34BD for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 17:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 P_FuHEamsZA6 for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 17:10:17 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 D79B41B2B0C for <tls@ietf.org>; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
Received: by mail-ig0-x236.google.com with SMTP id z14so24482706igp.0 for <tls@ietf.org>; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=T569sDQd9m7t8oGPVQ1dQmmuG/V3+9XSA747pWmcZEawYD7Hxg5j0cBEPEKi3/XSTZ V+7xEh2/n7XVx+fq6gIRM+cQ2xmjbb+/TB0UtMcCa4jBnWozJvx3yFpQ1rE6oyVcTzsE jHR7hXRWs5EfHt4T47igsfU+GaYRVmmJ4jr2Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=PB/KXGJOb2BZjmk+VdLVuxHhj2JWy0//5PtAj34F7oSRDWZgIZutOq3ZyFAHMoI/yO 2AMF0rZCs0ZnvD/gVNYcdVx1Ve4KveGLnlYCZ+1vI/HyNWFtXFjv8VfN7rJ7XUZm6pD/ R1FSLzWcJPY08RNOsgNulDDEkjgzKSaHQCOeDY8oY6yqhvs+jKNUCD7OkUYc19hcXROK vdYtLNV1WETMX139ghPMQqnG4JU9tl/Yx6yzzlPz8k4+BbxqydRGAvwmIv6hn81DgVQL OyZbPQJMEjVB66mp7gk5KlT7AmeRawQC6B78d8HxAON+UCZK4buywTHOqvKCZF4tJ/2X OSdg==
X-Gm-Message-State: AG10YORGAOxnEI8uLuLZqqE4331uMkYLpglNv8h6DAhkdFE844nSjqD266/Ce6ipz3ocMFdcVJBjOh19ttjfvDRC
X-Received: by 10.50.134.129 with SMTP id pk1mr1365490igb.11.1452906616225; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <CAFewVt7f4pAbJ_Z3s0w_Qiwdi-cGM-39BnPV5-qF3PLOdpFw0A@mail.gmail.com>
In-Reply-To: <CAFewVt7f4pAbJ_Z3s0w_Qiwdi-cGM-39BnPV5-qF3PLOdpFw0A@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 16 Jan 2016 01:10:06 +0000
Message-ID: <CAF8qwaBrzPtLzoAGAfjCzzHHxZzh97W3K53PMGmunJsF-SfVYg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary="047d7b2e3fe6c0b0e20529692ee5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AYaI8ag17cW4Ea5YYVxlw55F510>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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: Sat, 16 Jan 2016 01:10:19 -0000
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <brian@briansmith.org> wrote: > David Benjamin <davidben@chromium.org> wrote: > >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* >> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this >> introduces new premultiplications, it’s only 9 values with the pruned TLS >> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. >> > > Have you considered the possibility of using this mapping?: > > TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256. > TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384. > TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521. > > Then: > 1. You don't have to define any new values. > 2. The extension size would be smaller. > Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can lose them. I just wrote out all 9 without thinking about it much. Apart from "please don't cause me interop pain", I don't have strong opinions about how aggressively we prune the list. My main worry is, for better or worse (I realize this is a point of contention), some servers apply sigalgs to both CertificateVerify and certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a nuisance. Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though it would prevent them from adopting TLS 1.3 without switching certificates. Alternatively, if people decide that sigalgs and certificates officially have nothing to do with each other in TLS 1.3, then things are fine but we wouldn't have a way to negotiate such algorithms. I was hoping to avoid that issue for this proposal, but there is some interaction. (Whether such certificates exist on the web is probably answerable via CT logs, but I haven't checked.) If changing the existing meaning is a nuisance, another option is to continue to allocate new values but only define ecdsa_p256_sha256, ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset is) for TLS 1.3 and later. > 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. > (I don't have any particular affinity for that profile other than it seems > to have made choices that have historically been shown to be above average, > and it might be a good idea to avoid interop failure with other > implementations that might have a special affinity for it.) > What interop faliures are you worried about here? > - ecdsa_p256_sha384 >> - ecdsa_p256_sha512 >> - ecdsa_p384_sha256 >> > - ecdsa_p384_sha512 >> - ecdsa_p521_sha256 >> - ecdsa_p521_sha384 >> > > The subset of your proposed values I listed above do not seem helpful. For > example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get > truncated to 256 bits. > Good point. That makes some of the combinations unlikely. > [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7), >> RSA}, they should ignore it since hash 7 doesn't exist. >> > > I think we should expect more pure ECC (no RSA) deployments soon. In that > case, it would be better if new ECC-based values used the value "ECDSA" (3) > instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them > as support for RSA. > Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with 'ECDSA'. The same footnote applies. :-) I don't think it makes sense to strategically assign the second byte for new numbers. Either we believe TLS 1.2 implementations are unlikely to react to 0x0703 and not worry about it, or we believe they will and we reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to u16 hack is too silly and don't do it at all.) David
- [TLS] Simplifying signature algorithm negotiation David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Brian Smith
- Re: [TLS] Simplifying signature algorithm negotia… Dave Garrett
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Hanno Böck
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Brian Smith
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Nikos Mavrogiannopoulos
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Kurt Roeckx
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… Joseph Salowey
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla