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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
