Draft: draft-ietf-quic-tls

Commentary: In looking at , I realized that we had nowhere that addressed the basic concept of resumption . This is , I hope , all that we need to say on the subject . It talks about state and then the privacy implications of using resumption . I found less in the TLS 1.3 RFC on this subject than I might have liked to see . It only really addressed ticket reuse . So this is a little more verbose than is ideal . Oh , and there are new requirements here , but as they are restatements of existing requirements , I do n't think that this needs to be a design change . But I will happily switch to treating this as a design issue if anyone asks . 
 In the new section 5.4 . of the transport draft , " Required Operations on Connections " , we see a requirement that When implementing the server role , applications need to be able to : o ... o if Early Data is supported , retrieve application - controlled data from the client 's resumption ticket and enable rejecting Early Data based on that information . I read the corresponding text in the HTTP draft , and I understand that the idea is to remember the HTTP Settings when resuming an HTTP connection . That 's fine , but it seems to assume that tickets are tied to a specific ALPN . Otherwise , if a server supports several applications over the same port , then the clients need to keep track of the ALPN used when the ticket was received . There is no such requirement in TLS 1.3 proper . In Section 4.6.1 . of RFC 8446 , " New Session Ticket Message " , we can read that Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session . Notice that there is no mention of the ALPN . We can thus expect the ticket store to be indexed by SNI , plus also some consideration about certificate explained later in the text . There are of course lots of reason for a server to support multiple ALPN over a single port . For example , the server might support H3 and H3.1 . Or it might want to provide access over port 443 for DNS over QUIC , IMAP over QUIC or other such applications . With TLS 1.3 , they can do that , demux on the ALPN , and 0 - RTT will work fine . But if we make the session tickets application specific , that wo n't work . Which is why I think the idea of putting HTTP settings in the session ticket is ill conceived . 
 IIUC , while it is possible to use a session ticket when the SNI is the same , you can only use early data when ALPN also matches . Quoting from RFC 8446 section 4.2.10 : 
 I think that we can address this by saying that clients need to remember this state alongside any ticket . ( And we should make it clear that the server needs to remember this also . It does n't have to put things in the ticket , though that might make it easier for it to correctly remember . ) 
 I believe a comment is needed in 5.4 to at least remind the reader that other ALPN 's might receive the ticket and would not be able to make use of the settings data which therefore need coordination across token consumers . 
 As I stated in , it is my understanding that early - data can be used only when the ALPN matches , and therefore a QUIC stack is required to consult the application - specific data in the ticket only when the ALPN matches . Therefore I do not see any need for cross - application - protocol coordination . Am I missing something ? 
 Assuming things work as you say and a client receives a token from ALPN - X , and assuming the client does not remember tokens per ALPN , then you can have another ALPN named ALPN - Y in another session receiving the token generated for ALPN - X. If the ALPN - Y endpoint does not understand how to at least ignore ALPN - X data in the token , you can get undefined behaviour . 
 I do not think so . In the case you describe , the TLS stack will not indicate to the QUIC stack that 0 - RTT is acceptable because the ALPN is different . Therefore , the QUIC stack handling ALPN - Y would not use the application - protocol - specific data in the session ticket ( as it is expected to be used only when early data is acceptable - that 's what section 5.4 of the transport draft says ) . Hence no confusion . 
 OK - I do n't know enough about how TLS validates tokens - but if it does embed the ALPN in token validation , then the coordination I am asking for is already happening . 
 So this means that 0 - RTT does not work across protocols ? This is unfortunate because if a client connects for HTTP and then connects for WebRTC data , it can not use 0 - RTT for WebRTC . 
 Correct . That is the restriction of TLS 1.3 . 
 So spec - wise , I think we might want to change : " if Early Data is supported , retrieve application - controlled data from the client ’s resumption ticket and enable rejecting Early Data based on that information . " to " if Early Data is supported , and when the TLS protocol stack indicates that Early Data can be accepted , retrieve application - controlled data from the client ’s resumption ticket and enable rejecting Early Data based on that information . " as well as suggesting that the application protocol - specific information is to be associated rather than stored , as pointed out by in 
 I am not too worried about the server side . Servers that support multiple applications can put adequate information in the token , such as for example a server release number that points to the initial condition for multiple protocols . But I am concerned about clearly spelling out the client - side requirements , and I would rather see two parallel requirements : remember the initial conditions per ALPN+SNI , and remember the ticket per SNI . Note that we want fast rotation of tickets for privacy reasons -- use tickets at most once if possible . That works better if we do n't add rigidity , such as " only reuse tickets per SNI+ALPN " . I think that resuming across multiple ALPN is a valid scenario .  points out that it may not be well supported in TLS 1.3 , but we do n't want to further ossify the lack of support . Of course , none of that matters if we run all application protocols over HTTP . 
 I do n't think it 's " not well supported , " it 's entirely not permitted by TLS 1.3 . You can resume a session , saving crypto work , but there wo n't be early data on it . If TLS changes in a future version or extension , QUIC can match . However , the most recent update to the text on how you handle stored SETTINGS does have a case for not being able to recover the SETTINGS from last time , which would seem to apply if TLS permitted early data from a non - HTTP session . You get the defaults , until you see the SETTINGS frame . The required capability could include not finding any corresponding data in the ticket . 
 As I said in the text comment , this is good . Only open question is whether there should be a " privacy consideration " note in the security section .
Paragraph (version B):
QUIC can use the session resumption feature of TLS 1.3.  It does this
by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete.  Session resumption is the basis of 0-RTT, but
can be used without also enabling 0-RTT.
Paragraph (version B):
Endpoints that use session resumption might need to remember some
information about the current connection when creating a resumed
connection.  TLS requires that some information be retained; see
Section 4.6.1 of TLS13.  QUIC itself does not depend on any state
being retained when resuming a connection, unless 0-RTT is also used;
see enable-0rtt and Section 7.3.1 of QUIC-TRANSPORT.  Application
protocols could depend on state that is retained between resumed
connections.
Paragraph (version B):
Clients can store any state required for resumption along with the
session ticket.  Servers can use the session ticket to help carry
state.
Paragraph (version B):
Session resumption allows servers to link activity on the original
connection with the resumed connection, which might be a privacy
issue for clients.  Clients can choose not to enable resumption to
avoid creating this correlation.  Client SHOULD NOT reuse tickets as
that allows entities other than the server to correlate connections;
see Section C.4 of TLS13.
Paragraph (version A):
There are likely to be some real clangers here eventually, but the
current set of issues is well captured in the relevant sections of
the main text.
Paragraph (version A):
Never assume that because it isn't in the security considerations
section it doesn't affect security.  Most of this document does.
Paragraph (version B):
All of the security considerations that apply to TLS also apply to
the use of TLS in QUIC.  Reading all of TLS13 and its appendices is
the best way to gain an understanding of the security properties of
QUIC.
Paragraph (version B):
This section summarizes some of the more important security aspects
specific to the TLS integration, though there are many security-
relevant details in the remainder of the document.
Paragraph (version B):
Use of TLS session tickets allows servers and possibly other entities
to correlate connections made by the same client; see resumption for
details.