Hey all,
I would have liked, at this point, to write a nice note about how I've
got Early Data working. But I've got several problems with this, both
practical and standards related. This email concentrates on the
standards side.
The goal with this would be that on QUIC, we can connect, establish
TLS, perform authentication, binding, stream state configuration, and
eventually other things all within the first round-trip. This would
result in connections (or at least reconnections - some data needs
caching) to occur fast even on quite slow networks.
0RTT "Early Data" is replayable, so an attacker can extract it from
the QUIC connection (or TLS handshake on TCP) and re-send it. This can
be defeated by counters (as FAST defines in XEP-0484) or by ensuring
that the request is idempotent and carries no side-effects (as HTTP
recommends).
The counter works by defeating the replayability; HTTP's approach
means that the replayability no longer matters.
The problem with the counter approach we've taken to date is that this
immediately onflicts with cases where we do want to replay it for
legitimate reasons, such as Happy Eyeballs and similar approaches to
"racing" multiple connection attempts. On poor networks, a first
connection attempt might succeed, but the response is lost, causing
counters to be updated and subsequent attempts to be rejected.
The only alternative I can see is to defer any side effects until the
handshake completes, noting that this does include resource binding -
in particular resource conflict resolution, which often has quite
large side effects for the losing session. I think this seems vaguely
possible, but I worry I have forgotten other side effects.
The other potential problem is that the early data is sent, and
processed, before most channel binding types are available, in
particular the TLS Exporter type. I suspect - and if you know, please
chip in - that this is OK, in as much as if the handshake completes
with the session ticket and PSK then the original channel binding from
the first connection still holds, in effect, as proof that the
endpoints remain unchanged. But I would really like to know for sure.
Finally, I note that because we're reliant on handling the early data
before a client can receive the features, then either the client
should "just know" the available mechanisms for early data
authentication, or else it will need to be told in a previous session.
And IAP (XEP-0509) needs to work, so the actual features/config inputs
used to calculate that need to remain unchanged.
Anyway, would appreciate any notes/ideas others have on this area!
Dave.
