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.