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

From: Roel Peeters <[email-masked]>
Date: Tue, 8 Nov 2016 15:55:36 +0100

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.

https://securewww.esat.kuleuven.be/cosic/?p=6624

Best regards,

Roel Peeters and Jens Hermans

PS: 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 ...

---

From: Sean Turner <[email-masked]>
Date: Wed, 9 Nov 2016 02:28:45 +0530

I let this message through the moderator queue despite the link to the blog; next time please send your comments directly to the list.  Note that I wouldn’t necessarily expect anybody to pick up your points for you; PRs are welcome though.

spt

> On Nov 08, 2016, at 20:25, Roel Peeters <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Dave Garrett <[email-masked]>
Date: Tue, 8 Nov 2016 16:26:03 -0500

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

Why are you wondering about this? HRR is in the specification and there has been no discussion to remove it.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 9 Nov 2016 00:33:52 +0200

> https://securewww.esat.kuleuven.be/cosic/?p=6624

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
  confirmation.
- 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
  anyway.
- 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
  problems).
- 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.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Nov 2016 14:43:13 -0800

>   that the present ladder diagram is not sufficient.

Yeah, I'm taking this point to heart. I've been a bit swamped with
implementation
matters, but I'll get working on a state machine diagram.

-Ekr

---

From: Roel Peeters <[email-masked]>
Date: Tue, 8 Nov 2016 22:56:28 +0100

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 <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2016 16:14:39 +0900

This paragraph refers to the anti-downgrade mechanism described in 4.1.3.

-Ekr

On Wed, Nov 9, 2016 at 6:56 AM, Roel Peeters <[email-masked]>
wrote:

> 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
>