On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > By this point in the connection, there is proof that early_data has not > > > been replayed. The application doesn't necessarily know this when the > > early > > > data is first delivered, but it can find out later, which may be all that > > > some applications want. Clearly not all, as you point out: > > > > This is actually only useful if the application can cancel out effects > > of 0-RTT if handshake fails... Which tends to be fraught with peril to > > implement. > > > > Absolutely, but it doesn't seem like it would be any more perilous than the > danger of accepting 0-RTT data in the first place: at worst you process the > same replayed data, and at best you process less replayed data. (Unless > there's a perverse incentive problem created by providing a half-measure.)
If all 0-RTT data is idempotent (including after replay delay!), sure. However, if it isn't idempotent, you could get issues... > > The 0-RTT data is not part of ClientHello. It is sent in streaming > > manner (with handshake blocking if it hans't been completely sent by > > the time ServerFinished is received. > > > > ClientFinished does _not_ MAC 0-RTT data, even in case of successful > > transport. > > > > There's my confusion. I misinterpreted both the Zero-RTT diagram and the > table of handshake contexts under "Authentication Messages", specifically > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is > accepted, is the second Finished message from the client ("{Finished}") the > same message encrypted differently (using the handshake traffic secret)? No, there is no difference in ClientFinished in case of 0-RTT accept or reject (other than the contents of the CH and EE hashed in). > Is there a succinct explanation for the design choices around what is and > is not included in the handshake context? Being spread out over a year and > a half of mailing list messages makes it hard to track. :-) I'm concerned > that an on-path adversary that can slice-and-dice connections along MAC > context lines will be able to create mischief, so I'd like to be able to > convince myself that this isn't the case. The thing that protects the 0-RTT data from substitution is the record protection MACs that are made using key derived from the PSK secret. So if the PSK secret is unknown, the key for 0-RTT can't be derived, and as consequence, 0-RTT data can't be altered (there's end-of-data marker too, preventing truncation). And basically, ServerFinished MAC covers everything up to that point, and ClientFinished MAC covers the entiere handshake (0-RTT data not included). > And also, receiving 1-RTT data does not imply that the 0-RTT data > > itself was not replayed (just that any replay it is of didn't > > complete, assuming PSK keys are secret). > > > > Yeah, I get that now. It seems like a missed opportunity to detect mischief > after the fact, and could make for some interesting vulnerabilities for > stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT > data is "rm -rf *", but the adversary is able to swap out the early data > for a replayed "cd ~". That one is probably too obvious of an example to > happen in real life, but imagine some developer who maintains his or her > own tlstunnel hearing about 0-RTT and implementing early data for arbitrary > applications using that tunnel wrapper because "reduced latency!": if early > data were later authenticated, it would limit the scope of vulnerability to > only those things that could fit in that first flight. But because it can't > catch every possible replay-based attack, maybe such a measure would > provide only a false sense of security. Sigh. I have no desire to re-ignite > arguments from a year ago. You can't swap out 0-RTT data (without PSK keys). One can only create new connection attempts (that fail!) with the same 0-RTT data (and the same ClientHello) before or after the real connection (if any, it could be supressed, in which case you would get only failed handshakes with 0-RTT data). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls