On Tue, Jul 19, 2016 at 04:45:01PM +0200, Antoine Delignat-Lavaud wrote: > > 1. Signature forwarding with external PSK > > Currently, resumption context is only defined for resumption-based PSK, > which means that external PSKs are not protected against transcript > synchronization attacks. > > Before Cas Cremer's paper, this was particularly bad because the Finished > (which is bound cryptographically to the PSK) was not part of the handshake > log; therefore, all signatures could potentially be replayed. > However, even though Finished are now part of the log, the server signature > in PSK 1-RTT remains vulnerable (because the log is then ClientHello, > ServerHello, Certificate and thus has no Finished message to save us from > transcript synchronization).
Oh yeah, that. > 2. Proposals to bind log and PSK > > As an option B, we propose to always include an early finished in the log, > regardless of the handshake mode. > This comes with some complications that were discussed during the WG > meeting. Very notably, if this early finished is assumed to always come > after the ClientHello, then it must either a. mangled with the ClientHello > in an ugly way or b.send on the wire at all. > During the WG meeting, it was pointed out that regardless of whether a or b > is used, if the client proposes more than > one PSK, there needs to be more than one early finished. What about never sending it on the wire but still having it in hash just before ServerHello, using the actually used PSK key and PRF and logically sent by the client. Placing it before SH instead of after CH is because of interactions with restart/0-RTT. The logical sender matters for DTLS (uses message number on which side?). Pros: - Binds PSK into the log (dealing with the attack above) - Friendly to TLS 1.2 servers. - Can be made up on the spot, no need to compute multiple, no need to speculate (even if speculating on PSK). Cons: - Special case of message being hashed that doesn't appear on the wire, no percedent for this (only hs messages on wire not appearing in logs). - Can't be easily included in 0-RTT keymat. But then, seems kinda pointless to include it, as 0-RTT keymat already depends on all the same inputs (PSK#0 and CH). Of course, no idea just how nasty implementing this in various TLS stacks would be... Could be very nasty... -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
