Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <davidben@chromium.org> Tue, 19 January 2016 22:21 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 CB9CC1B36F5 for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 14:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.221
X-Spam-Level: *
X-Spam-Status: No, score=1.221 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, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 HD8GhOza4SiC for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 14:21:05 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 5BE311B36E1 for <tls@ietf.org>; Tue, 19 Jan 2016 14:21:05 -0800 (PST)
Received: by mail-ig0-x231.google.com with SMTP id mw1so438455igb.1 for <tls@ietf.org>; Tue, 19 Jan 2016 14:21:05 -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=DHnwz6ju8q1oUHKG+m2KG1EDqDLbLmaNDIQviPpvZFw=; b=ePUBI0lJ4gj0G4n+LN6rO0mveLMwCPi1sL42EMngpBKnu9SkZW2U14SU/KonNSsu+3 KOKytguM5+afvhMiwQ7fxTxKWxu8jenWnOQN0SX1VzTRY+j3ns+PGx+xs+/8++0tLQ2k gJWW3GAJZoMReQWIT/aYCrERjwetZzxROf3uw=
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=DHnwz6ju8q1oUHKG+m2KG1EDqDLbLmaNDIQviPpvZFw=; b=RfGgHKRp56e0ziFSi+AeR0LBSFWDRJTftatB//2W/0An/rLv5RiVoREtrIw/mzyr1s 5M0T/Wv9YE84N++cAEs4o3u9lsDlY3xxEFgVVz5h6b1WvcdvQ44C/smqdyAl+WD6ufOe y1IOu+JJgrk2R5rDTWefVEyQz40P4vBNuVowCQiUDe3lw2ecHrXQvwvZRd3KaeXeyEB/ ZBEsu7c+veZ7Q33DFQ4vZd+eb8egV8pH3pJYPMZTUY0s7KHE+UEiujQCFS1nyFEinIv8 CbIvJ7DkCcxZteVuo8YvyoWj1Zd9657rBPpdHAsgBbuKZNl7+2XqKM+pr7SG4PKSmctS FmXQ==
X-Gm-Message-State: AG10YOQPCAzNBOPoR3tRMVzyyw28Pw6iRmIn4WGAc1qtfcA1ncs6nNAuHyK2JeKay2GICwEo1MgSbDxMwyaM6BQi
X-Received: by 10.50.171.200 with SMTP id aw8mr312526igc.77.1453242064681; Tue, 19 Jan 2016 14:21:04 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <20160116110112.4af15baf@pc1> <CAF8qwaBymFWuM2c7DyeZy3JzB+Uh5YJs3+yfgRcwKLKSE6k1qQ@mail.gmail.com>
In-Reply-To: <CAF8qwaBymFWuM2c7DyeZy3JzB+Uh5YJs3+yfgRcwKLKSE6k1qQ@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 19 Jan 2016 22:20:55 +0000
Message-ID: <CAF8qwaD4xBjhzbQkA23kCvOP24a5WuzJVWcOvcHRs-Z-A2UfXw@mail.gmail.com>
To: =?UTF-8?Q?Hanno_B=C3=B6ck?= <hanno@hboeck.de>, tls@ietf.org
Content-Type: multipart/alternative; boundary=089e010d956209fd800529b749a0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_fW4asdDMa7d_AQgeajVj60lhq4>
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: Tue, 19 Jan 2016 22:21:06 -0000

Sorry, sent from the wrong address.

On Tue, Jan 19, 2016 at 5:19 PM David Benjamin <davidben@google.com>; wrote:

> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck <hanno@hboeck.de>; wrote:
>
>> Hi,
>>
>> I generally like the idea of simplifying the different algorithm
>> negotiation things, but:
>>
>> On Fri, 15 Jan 2016 20:45:34 +0000
>> David Benjamin <davidben@chromium.org>; wrote:
>>
>> > [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.
>>
>> I think a couple of them (esp. everything with dsa and _md5) should get
>> a diediedie rfc and never be seen again.
>>
>
> Sounds good. I included all the TLS 1.2 values thinking we'd want to
> retroactively express TLS 1.2 (DSA, MD5, and SHA-1 warts and all) this way
> too. But leaving it alone is probably simpler. Reserving the range should
> be sufficient to keep collisions out.
>
> If TLS 1.3 takes this proposal, I expect that I will make BoringSSL
> implement TLS 1.2 this way (with whatever quirks are needed around ECDSA)
> for convenience, but there's no reason this needs to be reflected in the
> spec.
>
>
>> > - 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
>>
>> Do we really need that many?
>> I think the "complexity zoo" of TLS is one of its current downsides and
>> I really think we should go with fewer options in the future. Can we
>> strip that down to - below 5 or something? (personal opinion: Strip
>> down to 2, but this may be too radical for now.)
>>
>
> Brian Smith proposed elsewhere in the thread to cutting the ECDSA ones
> down to just
> - ecdsa_p256_sha256
> - ecdsa_p384_sha384
> - ecdsa_p521_sha512
> and folding them into the TLS 1.2 compatibility ECDSA values, which I
> think I am in favor of. I'm personally okay losing P-521 too since
> BoringSSL doesn't advertise it, but I imagine others might object, so
> *shrug*.
>
> That brings us down to 8. No strong opinions from me on whether we need
> all three rsapss_* values. I just took what was in the 1.3 draft.
>
>
> David
>