Re: [TLS] COSIC's look on TLS 1.3

Roel Peeters <roel.peeters@esat.kuleuven.be> Tue, 08 November 2016 21:56 UTC

Return-Path: <roel.peeters@esat.kuleuven.be>
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 A4621129DFC for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 13:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 4QV_JgYlGxHR for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 13:56:34 -0800 (PST)
Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB79D129DFB for <tls@ietf.org>; Tue, 8 Nov 2016 13:56:33 -0800 (PST)
X-KULeuven-Envelope-From: roel.peeters@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 3406D1380B6.A7E4A
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 3406D1380B6 for <tls@ietf.org>; Tue, 8 Nov 2016 22:56:29 +0100 (CET)
Received: from [192.168.0.177] (d54C3A026.access.telenet.be [84.195.160.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPSA id 218AA2003B; Tue, 8 Nov 2016 22:56:29 +0100 (CET)
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Roel Peeters <roel.peeters@esat.kuleuven.be>
Message-Id: <8C67E8BB-B230-4C84-A890-C57614FF8A46@esat.kuleuven.be>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21C184F2-3379-4594-9607-4F932968041D"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Tue, 08 Nov 2016 22:56:28 +0100
In-Reply-To: <201611081626.03635.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> <201611081626.03635.davemgarrett@gmail.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r9Rr1QuiPnK6ZBri9ovHkrb9kpc>
X-Mailman-Approved-At: Wed, 16 Nov 2016 23:10:52 -0800
Cc: Jens Hermans <Jens.Hermans@esat.kuleuven.be>, tls@ietf.org
Subject: Re: [TLS] COSIC's look on TLS 1.3
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: Tue, 08 Nov 2016 21:56:35 -0000

Hi Dave,

We are wondering because of this piece of text from the RFC EDITOR just above paragraph 4.1.4 on Hello Retry Request:

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft versions (see Section 4.2.1.1) of this specification SHOULD NOT implement this mechanism on either client and server. A pre-RFC client connecting to RFC servers, or vice versa, will appear to downgrade to TLS 1.2. With the mechanism enabled, this will cause an interoperability failure.

Best,
Roel

> On 8 Nov 2016, at 22:26, Dave Garrett <davemgarrett@gmail.com> wrote:
> 
> On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote:
>> we are also wondering whether or not the Hello Retry Request will be
>> included or omitted in the standard. Leaving it out will make TLS 1.3
>> vulnerable again to downgrade attacks ...
> 
> Why are you wondering about this? HRR is in the specification and there has been no discussion to remove it.
> 
> 
> Dave