Re: [TLS] Simplifying signature algorithm negotiation

Eric Rescorla <ekr@rtfm.com> Thu, 17 March 2016 12:34 UTC

Return-Path: <ekr@rtfm.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 A0B9612D903 for <tls@ietfa.amsl.com>; Thu, 17 Mar 2016 05:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 u3ZmtvP9Euqu for <tls@ietfa.amsl.com>; Thu, 17 Mar 2016 05:34:03 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 E752E12D8F1 for <tls@ietf.org>; Thu, 17 Mar 2016 05:33:55 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id m126so73745054ywd.0 for <tls@ietf.org>; Thu, 17 Mar 2016 05:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R5mH2Ei9636HFCkXrHs3gajontPsbTyEEjygJOFjt+E=; b=rXPw9pOfoeqz7IJWJsLKS+1R9D3mjzrquX6bxK5uY1cCH9wTKXCfLPAUHR3zZgk9HM VVtPFeibGTvieT61vDN/pQe1d0mFZbORhakTocYlrekqb4OcApo2xG5NZ2z9ItY66pvA ZOf5n4eDVKpvZcigAREhUBj/q6G+LHmvRJZ2+ttfg5lpz+WHW99IZMSHW2Y4XMsyDVAu /QrchSUUmrvomlhGw0fffcA4gTvNTjybCNjr1AtEPNTxToCpxQoOqcpOBU/ofd5oXnAt zRgkJZlQs7Itj/m50T6HHMNC115NM558dbjoznX/XgXquUj6Jfxyor3J1pLFJ1YE76PA 5Fbg==
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; bh=R5mH2Ei9636HFCkXrHs3gajontPsbTyEEjygJOFjt+E=; b=LRdXFEOAY5qukdubGEkC8QgqmordvgchRxBARTLv765z/6J7fQhEqJZ/BxhPj1zqVg erhNM4uwUqKj7Tm5ZoqEhRmpcf9pYnnPnQ0VuGPYMoA972h3HlPGRUmHVQtOvmvohDR4 lFmT326f4P8Jz87SH+oNYKnBhHkaBm2aEXlW9gDUoce+5EVwJX4MI/XHlELZ6H+OX2kO g76h2O8n30xUj1n6eBzjkGJlh6APaJOIhdDogUWuy9uXHltyDL+wDYmAlv81TFlUxkhv 6z0UqdsMovKJ0CF7vY8BIKuBVB+nrUr4aDECt2tZrH4w1ehoV8xhNQ9ip8Mt+kElgw0H IpXQ==
X-Gm-Message-State: AD7BkJJNJejvq5jRtkVQAHkVU4Af0PUvRqom2w0gBonzOQFj3VDQyQdBA08G3sB4jZuvjGGv8oJblN302jFDUw==
X-Received: by 10.37.95.70 with SMTP id t67mr3903178ybb.82.1458218034877; Thu, 17 Mar 2016 05:33:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Thu, 17 Mar 2016 05:33:15 -0700 (PDT)
In-Reply-To: <CAF8qwaC3F0BTPV9V0d3SVwd0YtUbWex+U1s56gbHZ_0gmrWdSw@mail.gmail.com>
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> <CAF8qwaC3F0BTPV9V0d3SVwd0YtUbWex+U1s56gbHZ_0gmrWdSw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 17 Mar 2016 05:33:15 -0700
Message-ID: <CABcZeBP9A-_WZ=cjGkR-HbjUXfrh5jvA6Ntns9he=9XBqdPu+A@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=001a11423c44fb32f5052e3dd7f9
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fwUMmujchle41L-auaUwTlPgFFA>
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 12:34:05 -0000

On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin <davidben@chromium.org>;
wrote:

> 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.
>

Correct.


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?
>

I don't think we will be deprecating 1.5 for certs soon. I do see your
point about
1.5 for CertificateVerify



> 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
>>>>>
>>>>
>>>>