Draft: draft-ietf-quic-v2

Commentary: Incorporated all suggestions . My only concern about server MUST is that it involves mucking with TLS implementations again to encode version in the ticket . Would this be a real obstacle ] ? 
 for any implementation that uses BoringSSL ( and I suspect the OpenSSL API is the same way ) , adding the version to the ticket will not require modifying the TLS implementation at all because the TLS implementation already accepts an opaque blob of data from QUIC ( and that 's currently used for transport parameters and h3 settings , adding the QUIC version would be transparent to TLS ) . 
 I am a bit concerned that we are departing from the common pattern used in QUIC specification : " Clients MUST NOT do this particular vile thing ; server MAY terminate the connection if they catch the client doing it . " The purpose of the MUST NOT is to prevent the client from creating problems at the server . The purpose of the MAY is to encourage servers to do some enforcement , so bad client implementations have a good chance of being detected and do not become some entrenched practice . Telling the servers that they MUST enforce forces servers to dedicate resource to explicit detection , which may not be the right tradeoff for classes of servers , such as for example embedded servers with resource constraints . 
 that is true , however TLS has a common pattern which is to require servers to validate their tickets thoroughly . I guess we have to pick which common pattern we care about most . I still think having the MUST on both clients and servers will lead to better interoperability 
 maybe . The way I deal with that in the picoquic demo server is simple : the default transport parameters are set when the process start , and by default the STEK key is also set at process start . I suppose that embedded servers could just follow that tradeoff , i.e. , forget tickets issued before the last reboot in exchange for code simplicity . But the simple server only verifies that the version is " one of the supported versions " , does not check the ticket for that . So this is extra code . Not a ton of extra code , so I am not going to fight that too long . But still extra code . 
 I changed the MUST to a SHOULD . " Servers gon na do " , so what we write here does n't matter much , but I see no reason to create RFC violations where they 're not really needed , and on the off chance that some servers have a serious obstacle to doing this . 
 During the discussion of , 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  , 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 ca n't use  because there will have been a v1 resumption ticket ? Whereas an upgraded connection would have a v2 resumption ticket ? 
 What does this mean ? How does the client " learn " that the server speaks v2 if the server did n'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 would n'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 are n't reusable , then it has to lose an RTT by not doing  . 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 and 1 ) Clients MUST NOT use a resumption ticket from a QUIC connection and apply it to another version . 2 ) 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 . 3 ) 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 We ca n'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 . 
 I 'm not 100 % firm on the server " MUST " , but I really think we should consider it .
Note that version 2 meets that document's definition of a compatible
version with version 1.  Therefore, v2-capable servers MUST use
compatible version negotiation unless they do not support version 1.
QUIC version 2 is not intended to deprecate version 1.  Endpoints
that support version 2 might continue support for version 1 to
maximize compatibility with clients.  In particular, HTTP clients
often use Alt-Svc RFC7838 to discover QUIC support.  As this
mechanism does not currently distinguish between QUIC versions, HTTP
servers that support multiple versions reduce the probability of
incompatibility and the cost associated with QUIC version negotiation
or TCP fallback.  For example, an origin advertising support for "h3"
in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC
version used by HTTP/3 and therefore some clients will only support
that version.
TLS session tickets are specific to the QUIC version of the
connection that provided them.  Clients MUST NOT use a session ticket
from a QUICv1 connection to initiate a QUICv2 connection, or vice
versa.
Servers SHOULD validate the originating version of any session ticket
and not resume from any ticket issued from a different version.  This
results in falling back to a full TLS handshake, without 0-RTT.
After compatible version negotiation, any resulting session ticket
maps to the negotiated version rather than original one.