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

[Ilari Liusvaara <[e-mail]>]

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