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