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

Ilari Liusvaara <> Tue, 08 November 2016 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 284EF1294E4 for <>; Tue, 8 Nov 2016 14:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P-8COYRm6EfA for <>; Tue, 8 Nov 2016 14:33:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AF9BD1294BC for <>; Tue, 8 Nov 2016 14:33:57 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3DE616402; Wed, 9 Nov 2016 00:33:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id LjxxY2wrKVre; Wed, 9 Nov 2016 00:33:55 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4AE2F289; Wed, 9 Nov 2016 00:33:55 +0200 (EET)
Date: Wed, 09 Nov 2016 00:33:52 +0200
From: Ilari Liusvaara <>
To: Roel Peeters <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: Jens Hermans <>,
Subject: Re: [TLS] COSIC's look on TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2016 22:34:00 -0000

On Tue, Nov 08, 2016 at 03:55:36PM +0100, Roel Peeters wrote:
> Dear all,
> just to let you know that we have written a blog post on the current TLS
> 1.3 draft, with our remarks that might be of use in your upcoming meeting.

Some comments:

- I would expect ClientHello to identify the TLS library client uses,
  by fingerprinting ClientHello. E.g. btls has very characteristic
  ClientHello (Elliptic curve 30  and signature 0x0808 are very rare).
- Outside statically provisioned PSKs, the PSK identifiers are supposed
  to be use-once (or at most use few times tightly spaced).
- Speed matters, therefore TLS 1.3 has been designed with the greatest
  speed -> 2 client flights and 1 server flight till data transport
  is fully up. Which is theoretical minimum for any protocol with key
- Checks have bad tendency of being omitted, so I personally prefer
  more complex key schedule that can force the properies.
- The state machine complexity mostly comes from all the messages in
  the handshake, none really seems removable/mergeable without
  introducing more problems.
- The obfustication is meant for one purpose only: Prventing attackers
  from correlating dynamic PSK connection with its parent. Note that
  masking is additive, so even multiple-use of the same PSK does not
  allow correlation of parent session. The child sessions would be
  correlated, but those are easily correlated by the identifiers
- Yes,the correct way is to invalidate tickets on use. The reason the
  mechanism is done this way is to support stateful and stateless as
  good as possible (obviously, stateless mechanisms have inherit
- Regarding 0-RTT data, yes it scares me... If just for the fact that
  it appears to be much more difficult to analyze than just about
  anything else (another scary feature is post-handshake auth, given the
  possiblities for applications to seriously shoot themselves to the
  foot with it, in non-obvious ways).
- Receiving the same PSK twice is only possible within the same
  connection: Because associated PSK master key will be different on
  every connection attempt, and forcing it to be the same would require
  breaking the PRF hash (which already causes severe issues).
- Even if client reuses PSKs, unless the ClientHellos are exactly the
  same (including Random field, which is supposed to be 256 random
  bits), the keys will almost certainly be forced different (if PRF
  hash is strong). This also holds for 0-RTT keys.
- Yeah, there have been complaints about lack of state diagram, stating
  that the present ladder diagram is not sufficient.