Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 13 July 2015 04:41 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 8C5551A8AF9 for <tls@ietfa.amsl.com>; Sun, 12 Jul 2015 21:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 NHJWe-4Gqog3 for <tls@ietfa.amsl.com>; Sun, 12 Jul 2015 21:41:06 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B191A903E for <tls@ietf.org>; Sun, 12 Jul 2015 21:41:06 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 909D9284D6A; Mon, 13 Jul 2015 04:41:04 +0000 (UTC)
Date: Mon, 13 Jul 2015 04:41:04 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150713044104.GK28047@mournblade.imrryr.org>
References: <CALuAYvbteowTeyWe9VneRHgyvzTRS3LfKdorWt=jmEy2k+wNqw@mail.gmail.com> <201507111709.27725.davemgarrett@gmail.com> <CABcZeBNCBrNeMKm5hCLQ741zFRpcXQ321onofH2EWJbiQrSs6w@mail.gmail.com> <201507111929.02696.davemgarrett@gmail.com> <BLUPR03MB13965B49B433823B6A04B3088C9C0@BLUPR03MB1396.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB13965B49B433823B6A04B3088C9C0@BLUPR03MB1396.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9m6-hjuYZKj2XuIwlSSm36-dLbs>
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 13 Jul 2015 04:41:07 -0000

On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote:

> I'm not happy with this either. The spec already says:
> 
>   "If the client supports only the default hash and signature algorithms
>    (listed in this section), it MAY omit the signature_algorithms
>    extension.  If the client does not support the default algorithms, or
>    supports other hash and signature algorithms (and it is willing to
>    use them for verifying messages sent by the server, i.e., server
>    certificates and server key exchange), it MUST send the
>    signature_algorithms extension, listing the algorithms it is willing
>    to accept."
> 
> This seems to be pretty clear: if the client properly advertises the
> algorithms it supports, then the handshake has a deterministic outcome.

That's all fine, we're talking about what the server should do when
it is certificate chain does not (in its entirety) match those
algorithms.  And in the context of TLS 1.3 which is not yet set in
stone.  

Which part are you objecting to?  The subsequent proposal to suppress
SHA-1 advertisements (if the client supports only TLS 1.3 or later)
when even when the client is willing to accept a SHA-1 chain when
all else fails?  That too seems sensible, and it was already noted
that clients will need to send the SHA-1 codepoint when willing to
accept TLS 1.2, since that spec does not contain the proposed new
language for server-side behaviour.

-- 
	Viktor.