QUICv2 should not allow TLS resumption with QUICv1 tickets
DavidSchinazi opened this issue · comments
During the discussion of quicwg/version-negotiation#68, we came to the conclusion that it was simplest and safest to ban TLS resumption across QUIC versions. The version negotiation draft will mention this, but without normative text because TLS is not a QUIC invariant. The QUICv2 draft should add normative text to explicitly ban resuming TLS across versions.
Does this consensus apply to compatible VN? If the client initiates with v1 and a v1 resumption ticket, can the server upgrade it to v2 and still respect the 0RTT, etc?
IIUC, this means that if the client connects with v1 and learns that the server does v2, but there's no upgrade, if the client decides to connect next time with v2 it can't use 0RTT because there will have been a v1 resumption ticket? Whereas an upgraded connection would have a v2 resumption ticket?
if the client connects with v1 and learns that the server does v2
What does this mean? How does the client "learn" that the server speaks v2 if the server didn't perform compatible VN from v1 to v2?
if the client connects with v1 and learns that the server does v2
What does this mean? How does the client "learn" that the server speaks v2 if the server didn't perform compatible VN from v1 to v2?
If the server does not upgrade, but it learns about available versions via the TP.
The server's Other Versions field exists to prevent downgrades in incompatible VN. There's no text suggesting that clients remember that information for use outside of the current connection.
That may not have been your intent, but why wouldn't a client do this?
This issue is hopelessly intertwined with other issues, like how we handle ALPN. I am not equipped to evaluate the claim that cross-version use of tags will cause a security problem, although as I understand it this sentiment is a concern rather than an established threat.
However: the use case I am concerned about involves a client learning about an incompatible version via the supported_versions TP, and choosing to connect to that version. If the resumption tags aren't reusable, then it has to lose an RTT by not doing 0RTT. Relying on incompatible VN would be two RTTs before data arrives.
Granted, v1 and v2 are not incompatible. But if it's not actually unsafe, I'd rather set a precedent that works for future, incompatible versions.
Outcome of offline discussion with @martinthomson and @DavidSchinazi:
-
Clients MUST NOT use a resumption ticket from a QUIC connection and apply it to another version.
-
Servers SHOULD validate that resumption tickets are not being used across QUIC versions and refuse to honor the ticket (or terminate the connection?) if they are.
-
Make it clear that the resumption ticket from a connection that did compatible VN maps to the negotiated version, not the original one.
Wow, that was a fast shift back to "SHOULD". I missed that.
I did a little digging and it seems like there is a different determination for 0-RTT and resumption in our code. Accepting 0-RTT is something that needs to be controlled, but resumption has no similar controls. In that, we're in a similar position to @huitema. We can't really stop resumption without first performing a little surgery on the TLS stack.
With that in mind, I'm conditionally OK with this resolution. That's a purely pragmatic decision on my part on the basis that "compatible" in this case means not really changing anything about TLS.