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
