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 14:37 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 5182E1B2B3D for <tls@ietfa.amsl.com>; Mon, 13 Jul 2015 07:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 LCovk3DLZkYc for <tls@ietfa.amsl.com>; Mon, 13 Jul 2015 07:37:30 -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 095D11B2B2F for <tls@ietf.org>; Mon, 13 Jul 2015 07:37:29 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 28E0D284D6A; Mon, 13 Jul 2015 14:37:29 +0000 (UTC)
Date: Mon, 13 Jul 2015 14:37:29 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150713143728.GN28047@mournblade.imrryr.org>
References: <CALuAYvYXHF0FQg_q2F0Q6vW-i3JFFSn+cCup+ErcQD-u4aGVHA@mail.gmail.com> <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150713143006.2463E1A1DC@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yCqNQmXEn0cAbxgm0tY1FfVp_Ww>
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 14:37:36 -0000

On Mon, Jul 13, 2015 at 04:30:06PM +0200, Martin Rex wrote:

> Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
> for a client that does not use Hello Extensions.

Let's not go back to lawyering the RFCs.  We've been there already,
with not much success.  I think we can reach consensus around the
proposed new language that fixes the specification defect for TLS 1.3.

Once that's done, where necessary, we can suggest to implementors
of TLS 1.2 to "improve the product by not complying with section
7.4.1.4.1 of RFC 5246 in a future release".

I am confident this has a much better chance of success than trying
to convince folks that their reading of the RFC is incorrect.

And in any case, when the client *does* send a supported algorithms
extension, that should *still* not rigidly constrain the server to
a certificate chain with just those algorithms,  Rather, as proposed,
the server should strive to vend a chain with just the supported
algorithms if at all possible, but failing that it should continue
the handshake with some suitable chain it has at its disposal.

-- 
	Viktor.