Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <davidben@chromium.org> Thu, 17 March 2016 00:47 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95312D889 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 17:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 DN0TyHtNIvcx for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 17:47:35 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 087D712D9C9 for <tls@ietf.org>; Wed, 16 Mar 2016 17:47:33 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id g184so23175029ioa.3 for <tls@ietf.org>; Wed, 16 Mar 2016 17:47:32 -0700 (PDT)
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; bh=oylOs+UyQKFDZ2cdNBWoOl80mWnGqviyMWcYKpe2uQI=; b=JYPAKHVmify6nBSX1wBdzlVtakPaz4Y3ASjNzlq74506kS3rn0OU9J6iq7ZA8MtW/v V2IRZjvl4vMJEjuaIzGYvPCL0s6bXC+RJbu0wKAab1Vyz+PrzkiomCxVzK67FpyMeYVM HBkT9E7KMAOB4BNzUcVHmcLVhlRbx6VsfLioU=
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; bh=oylOs+UyQKFDZ2cdNBWoOl80mWnGqviyMWcYKpe2uQI=; b=XJHkYsg7I2iWJYlj5HJ/LFAG7CnBxMw+0QyG0SpqYEpHFIHyEI2o1rjvVDi0HBKb+z w6fhd4tAM/kLUE0pteum2xk4UofXZgBKgB0nVUKJE6yfcEeIJ7j1OCZrAA6tsutMJRPt Vh+eqctFbAXvWAc+gygE2yenk0TOwYh+waP3/YTgzgbSVO2vvgxD3IoJlmlWRYMe4HYM gHqaBZ80qFCuljY45jgjERU3wA84NZFFXKhNiw58XcN0bXVVuNPOmLN0SieGPnt8QkNx VQrteJNGRBrrbQzgQo3G3EdGxV3U+K37YXIAH+cCzBK03UWAUC7yAGITfrKEyISpZeGa j7/Q==
X-Gm-Message-State: AD7BkJLjyBFT47gTe7bOkGswIg2xdv7y1ENZfkGfyc0nuVi2xnW5Ndozgh6vCqGoQx8Sqymbv84w8cvgSawUHbuU
X-Received: by 10.107.136.167 with SMTP id s39mr6670063ioi.120.1458175652193; Wed, 16 Mar 2016 17:47:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <201601152007.12464.davemgarrett@gmail.com> <CAF8qwaBPsLz-vuOvXGZgxzMpaKHwtZixu7NXzfFN4V_R6WT8Tg@mail.gmail.com> <CABcZeBNipj4oLU=FrTp3+CqTg5bh5vBnd04DoNt56=8BRjqobw@mail.gmail.com> <CAF8qwaDUbLmvzibuC7aedOR5TP6Fv3rNz6ft_v3bKu=FHatYgg@mail.gmail.com> <CABcZeBMGnma86M24hzQw6zmwftMte2Lr34TGuq2pUF0MTGZMUQ@mail.gmail.com> <CAF8qwaDdi9JNNKUCBsuQmw3AssaiKvMgSs_8bCebfmBRdzCAQw@mail.gmail.com> <CABcZeBPUM4YmeUfzE8_jj6CqOQ5t1Q-82kU7jA3xg1XF+Pd0ng@mail.gmail.com>
In-Reply-To: <CABcZeBPUM4YmeUfzE8_jj6CqOQ5t1Q-82kU7jA3xg1XF+Pd0ng@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 17 Mar 2016 00:47:21 +0000
Message-ID: <CAF8qwaC3F0BTPV9V0d3SVwd0YtUbWex+U1s56gbHZ_0gmrWdSw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a113eba3cc5471f052e33f979
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HwHTZUFq-j0itjJPPZWezbAg5Gg>
Cc: ekr <notifications@github.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Mar 2016 00:47:38 -0000

On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla <ekr@rtfm.com>; wrote:

> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <davidben@chromium.org>;
> wrote:
>
>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com>; wrote:
>>
>>> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then
>>> we'll probably want to define
>>>
>>   code points for 1.5 in both in-protocol (CertificateVerify) and
>>> certificates to distinguish these.
>>>
>>
>> Oh? Why would they need to be separate? The others defined for both
>> aren't.
>>
>
> The idea here would be that we want to be able to deprecate the use of
> v1.5 in
> CertificateVerify before its us in certs (which we can't deprecate for
> quite some
> time).
>

Gotcha. This is true independent of this change, right? Without it, we'd
need to define two v1.5 SignatureAlgorithm values instead.

I'm not sure this is worth the nuisance. If we expect to deprecate it soon,
we should just keep it out of 1.3. If not, we only need to advertise
removal if there are v1.5-preferring servers that can sign anything else,
in which case why aren't they signing that to begin with? Otherwise
rejecting v1.5 is going to break those servers regardless. (Then again,
with SHA-1 vs. SHA-256 in ServerKeyExchange, I myself found
SHA-1-preferring SHA-256-capable servers, which is baffling. Would be good
if 1.3 implementers didn't repeat that one...) Should we split all other
code points in anticipation of deprecating them? Why not a separate
extension altogether then?

Anyway, I think this is orthogonal. We can certainly allocate more v1.5
code points in either universe if people want that. *shrug*

David


> -Ekr
>
>
>>
>> David
>>
>>
>>> As far as process, it seemed like people were generally positive about
>>> this in this discussion,
>>> but I'll rely on the chairs to determine consensus.
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <davidben@chromium.org>;
>>> wrote:
>>>
>>>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com>; wrote:
>>>>
>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.org
>>>>> > wrote:
>>>>>
>>>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com>;
>>>>>> wrote:
>>>>>>
>>>>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>>>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm.
>>>>>>> In TLS
>>>>>>> > 1.2, signature algorithms are spread across the handshake.
>>>>>>> [...]
>>>>>>> > I propose we fold the negotiable parameters under one name.
>>>>>>> [...]
>>>>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm,
>>>>>>> SignatureAndHashAlgorithm as
>>>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and
>>>>>>> negotiate that
>>>>>>> > instead.
>>>>>>>
>>>>>>> I previously proposed this here:
>>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html
>>>>>>>
>>>>>>> ekr was against it, though it hasn't been discussed that throughly.
>>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html
>>>>>>
>>>>>>
>>>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it
>>>>>> and forgot.
>>>>>>
>>>>>> ekr, are you still against this sort of thing? I think the new CFRG
>>>>>> signature algorithms tying decisions together is a good argument for why
>>>>>> we'd want this. If we believe this trend is to continue (and I hope it
>>>>>> does. Ed25519 is a nice and simple interface), trying to decompose it all
>>>>>> seems poor.
>>>>>>
>>>>>
>>>>> I'm not sure. I agree that the CFRG thing seems to be a new
>>>>> development. I'll
>>>>> try to confirm my previous opinion or develop a new one over the
>>>>> weekend :)
>>>>>
>>>>
>>>> ekr, did you have confirmed or new thoughts on this change?
>>>>
>>>> From elsewhere in the thread, I put together a draft PR if you wanted
>>>> something to look at in that form.
>>>> https://github.com/tlswg/tls13-spec/pull/404
>>>> It incorporated some of the suggestions in the thread (not mentioning
>>>> the really legacy values, pairing NIST curves with hashes, etc.), but
>>>> that's not the important part. The meat of the proposal is unifying
>>>> signature algorithms under one number and a shared interface, which I think
>>>> is a valuable simplification.
>>>>
>>>> David
>>>>
>>>
>>>