Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <davidben@chromium.org> Mon, 25 January 2016 17:35 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 1B3E41B37B8 for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 09:35:47 -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 c6w6HaDIStmS for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 09:35:44 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 411E31B37B6 for <tls@ietf.org>; Mon, 25 Jan 2016 09:35:44 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id ik10so39339544igb.1 for <tls@ietf.org>; Mon, 25 Jan 2016 09:35:44 -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 :content-type; bh=dafEfVT8CmPhKAksvpgVVMhUFTjPUq/pbWywgqQDrKw=; b=eThDf4saGyiF04j2Xr7ZRfsaIWR/FiaEZ9DJMboknh/UPF1Wy0iFjMgmTAyUnD+XvT v1cai8Q8We/q82EhE4R/HoGwSsfHM6L49bVsnEQA8xyr7mDl3uEgoyav+u0rvl4YSFuZ e+Easnkfh5A0gSFEQ1RoieZbNQs17EDbCHa9Y=
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:content-type; bh=dafEfVT8CmPhKAksvpgVVMhUFTjPUq/pbWywgqQDrKw=; b=Oj0uR1T9w9jEU+sgaOwxOjlvkxlXFOo/zzR//6aHR+VOAUXThkL5oOShu+XPt+vNc+ EpZgTwXd+Ca+Vmc3WFI83KVr2siyeEJDmvw2w+moY+cwIaKfDCalAgOIUd36hE85rJiq bxMJY1DveoGLeUb4o2mOi/m3vsg0vbirBHuGA09hXmTxTZ5TO9oNXG70ImCB66jegfAk uTa2ic5+UNETvutB3UKhjhSmOq8S/XDcon6rjuDfscqddMUOP2rePqPBuIqh/F5d1IEa qKFPcyNKI8fgJgv68Pln//sTLJ/Qh0NpVa7OnqP4YF+E5XjARLVw3Kf57A4C8K4u5yeQ PvFA==
X-Gm-Message-State: AG10YOTVLw95JlusPcD3uI+aXzQShIfROwT9vptKBBXBWQRFVgv+X0H1tdz27tZvQV17bzmvadc5C2nTj6quDI9P
X-Received: by 10.50.8.106 with SMTP id q10mr17681520iga.67.1453743343579; Mon, 25 Jan 2016 09:35:43 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <CAF8qwaC8oSnCgs7Nv+=extiHkddNE-n5z4GXtBtcH-N43O6_4Q@mail.gmail.com>
In-Reply-To: <CAF8qwaC8oSnCgs7Nv+=extiHkddNE-n5z4GXtBtcH-N43O6_4Q@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 25 Jan 2016 17:35:33 +0000
Message-ID: <CAF8qwaChgeA9BZdt7=11a3Trrqtd8X3mCgk9wBFi103JvoykMA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e013c65dc96f30b052a2bff8b
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/g3y6NltrXnw3k8-6QXYUcPbABNs>
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: Mon, 25 Jan 2016 17:35:47 -0000

Sorry, I'd meant to add this note to the message below and forgot:

In putting together the PR, I noticed that eddsa is currently in the draft
as always paired with no hash rather than the one it uses internally. So
the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur.
My bad, I should have looked at that more carefully.

I still think this change is worthwhile. If we expect that future signature
algorithms look like ed25519, this scheme only gives us 256 values to
allocate from and wastes one of the bytes, and it also simplifies and
unifies the interface for signature algorithms. The other benefits from
incorporating curve preferences into the negotiation also still apply.

David

On Fri, Jan 22, 2016 at 5:25 PM David Benjamin <davidben@chromium.org>;
wrote:

> I've put together a pull request with some initial text for this proposal
> if folks decide to adopt it.
> https://github.com/tlswg/tls13-spec/pull/404
>
> (I'm sure there's no end of editorial problems. I think this is the first
> time I've done non-trival spec work.)
>
> David
>
>
> On Fri, Jan 15, 2016 at 3:45 PM David Benjamin <davidben@chromium.org>;
> wrote:
>
>> Hi folks,
>>
>> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
>> 1.2, signature algorithms are spread across the handshake. We have
>> SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
>> independent registries. NamedGroup is sent in one list, also used for
>> (EC)DH, while the other two are sent as a pair of (HashAlgorithm,
>> SignatureAlgorithm) tuples but live in separate registries.
>>
>> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to
>> be messy to implement. Client certificate keys may be in smartcards via
>> OS-specific APIs, so a lot of time is spent transiting new preference
>> shapes across API boundaries in order to discover smartcard bugs. Sometimes
>> I think people deploy client certs because they hate me and want to cause
>> me pain… :-)
>>
>> Anyway, the new CFRG curves also bind signature curve and hash together.
>> The current draft represents this as eddsa_ed25519 and eddsa_ed448
>> NamedGroups and eddsa SignatureAlgorithm. But this doesn’t capture that
>> EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.)
>>
>> I propose we fold the negotiable parameters under one name. Think of how
>> we’ve all settled on AEADs being a good named primitive with a common type
>> signature[1]. Specifically:
>>
>> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
>> on, NamedGroup is only used for (EC)DH.
>>
>> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as
>> they are. Introduce a new SignatureAlgorithm u16 type and negotiate that
>> instead. (Or maybe a different name to not collide.) u8 is a little tight
>> to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty.
>>
>> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by
>> (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401
>> becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with
>> HashAlgorithm from TLS 1.2. Note this does not introduce new
>> premultiplications on the wire. Just in the spec and registry.
>>
>> 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.
>>
>> 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
>> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and
>> curve pre-specified. (See [2] at the bottom for full list of allocations.)
>>
>> Thoughts?
>>
>> David
>>
>> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping
>> to a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
>> hashAlgorithm SHA-256, maskGenAlgorithm
>> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14.
>> And RSA key generation still has size parameter. Hopefully future things
>> can look more like Ed25519.
>>
>> [2]
>> 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
>> this is wire-compatible with TLS 1.2.
>> - 0x0101 - rsa_pkcs1_md5
>> - 0x0201 - rsa_pkcs1_sha1
>> - 0x0301 - rsa_pkcs1_sha224
>> - 0x0401 - rsa_pkcs1_sha256
>> - 0x0501 - rsa_pkcs1_sha334
>> - 0x0601 - rsa_pkcs1_sha512
>> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
>> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but
>> ignored in TLS 1.3.
>>
>> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to
>> avoid colliding with existing signature algorithms, but I don’t think
>> that’s necessary[3].
>> - rsapss_sha256
>> - rsapss_sha384
>> - rsapss_sha512
>> - ecdsa_p256_sha256
>> - ecdsa_p256_sha384
>> - ecdsa_p256_sha512
>> - ecdsa_p384_sha256
>> - ecdsa_p384_sha384
>> - ecdsa_p384_sha512
>> - ecdsa_p521_sha256
>> - ecdsa_p521_sha384
>> - ecdsa_p521_sha512
>> - eddsa_ed25519
>> - eddsa_ed448
>>
>> 0xfe00-0xffff - reserved for private use, compatible with existing
>> HashAlgorithm reservation.
>>
>> [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.
>>
>