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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 13 July 2015 16:28 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 CA7C91B2C25 for <tls@ietfa.amsl.com>; Mon, 13 Jul 2015 09:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 QgYtg2MzIFh6 for <tls@ietfa.amsl.com>; Mon, 13 Jul 2015 09:28:13 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCC11B2C1D for <tls@ietf.org>; Mon, 13 Jul 2015 09:28:13 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 10A5B1A28A6; Mon, 13 Jul 2015 19:28:10 +0300 (EEST)
Date: Mon, 13 Jul 2015 19:28:10 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Rex <mrex@sap.com>
Message-ID: <20150713162810.GA21594@LK-Perkele-VII>
References: <201507131040.35143.davemgarrett@gmail.com> <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20150713161052.1946D1A1DD@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_S-syuDXyjSYO31oXS_cmjxL_1g>
Cc: "tls@ietf.org" <tls@ietf.org>
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
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 16:28:15 -0000

On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:
> Dave Garrett wrote:
> > On Monday, July 13, 2015 10:30:06 am 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.
> > 
> > If you want to put it that way, sure, however they are NOT irrelevant
> > for a _server_ that does use hello extensions. This is a direct part
> > of the TLS 1.2 spec,
> 
> That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible with
> rfc2119 section 6.  As it can be easily verified, the behaviour
> described in rfc5246 is detrimental to interoperability and security.

I don't see such conflict (except with TLS 1.0/1.1 client with TLS 1.2
server). The scenarios where that sort of behaviour would cause actual
interop trouble (meaning it could have worked otherwise, assuming non-
buggy client/server) are:

- TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2
  server. Or
- Server cert chain contains certificates TLS 1.2+ client does not care
  about (e.g. TLSA or excess certificates).

The proposed changes for TLS 1.3 are for the latter case.

(Then there is whole separate question on how compatible inter-
operability and security are, and the answer seems to be not very).


-Ilari