Draft: draft-ietf-quic-transport

Commentary: While in theory a client could send 0 - RTT after receiving 1 - RTT , this is not a good idea . This PR ties down transport parameters and flow control and prevents a client from using anything it learns in the handshake or 1 - RTT from affecting ( or expanding ) what it can do with 0 - RTT . This prevents a client from using 0 - RTT indefinitely and creates stronger bounds on what 0 - RTT can be used for . 
 I think it 's possible . I think that 's what the PR is trying to suggest is that a server can : enforce limits based on TP to streams - related frames sent using 0 - RTT packets ( see ) refuse to handle any of the following frames in a 0 - RTT packet : ACK , PATHRESPONSE ,  ( see ) 
 Actually , enforce limits based on the TP from last time * which are embedded in the session ticket . But yes -- the " correct " way of doing this is saying that there is a parallel set of flow control limits which never increase from the initial value , but which only apply during 0 - RTT . If the client always switches to 1 - RTT ASAP , this will be the same as regular flow control provided that the client does n't consume any higher initial flow control values in the transport parameters until the handshake completes . 
 I tend to agree with that policing limits here will be annoying , even if it is theoretically possible . Thankfully , we get most of the benefits if only a small number of implementations police limits . 
 I know we agreed to this is Tokyo , but seeing the actual PR made me realize how complex and hard to enforce this is . Would it be possible to solve the issue in a simpler way by saying something along the lines of the following ? That way clients ca n't keep sending 0 - RTT forever since they 'll have to send a 1 - RTT ACK to unblock the server - to - client flow control at some point . 
 This is already the case . It fails to solve any of the problems we are with though . 
 if you want to change the decision at the interim , that 's decidedly a question for the issue / list . can you point to that restriction ? I agree that it 's intended , but I ca n't find it . If we have that , you have to ignore 0 - RTT packets sent after 1 - RTT has started . If you withhold putting any increases in flow control into effect until you 've seen that 1 - RTT packet , you 're done fixing the problem we discussed . That might be a simpler way to describe ( or at least to implement ) this prohibition . 
 says : We already have issues on file for not reading 1 - RTT and then sending more 0 - RTT . They even have PRs . As for the suggestion , the problems we have do n't relate to the 0 - RTT to 1 - RTT transition , they are about key updates and the transition between Initial and Handshake and 1 - RTT . 
 Ah , I was looking in -transport . That prohibits the client from going back to 0 - RTT , and prohibits the server from accepting 0 - RTT starting 3RTO after the server first sends a 1 - RTT packet , but does n't appear to require the server to check that the client did n't reverse itself by dropping packets . ( This is the issue / PR about not allowing the client to stay in 1 - RTT , is n't it ? ) 
 Gah , too many windows . Sorry . 
 I would n't say I 'm explicitly trying to change anything decided in Tokyo , I 'm trying to understand why I 'm failing to understand what problem this PR solves . the text you pasted from -tls does n't match what I suggested : So I do n't think we already do that . Could you elaborate on what problem is solved by this PR that would n't be solved by my check above ? 
 ( To be clear , pasted the URL again as the quote , and I expanded it to some of the relevant text , so blame me if I got the wrong bit of 4.9 ) I think what he was meaning to point to was this : currently - available encryption level . Only ACK frames and retransmissions of data in CRYPTO frames are sent at a previous encryption level . These packets MAY also include PADDING frames . So the client is prohibited from doing that , but the server is n't currently obligated to check . I 've tried to create something along the lines you suggest in -- can you take a look ? 
 Too little sleep . I still think that this is better than . Comments why over there . 
 I am not sure if this is accurate . IIUC their is nothing that mandates the client to switch to using 1 - RTT when it receives ServerFinished . In fact , on a lossy network , a client would benefit from using 0 - RTT packets until it receives an ACK for ClientFinished . In such case , it would be natural to observe these frames in a 0 - RTT packet . I think we should either forbid them or clarify that there are allowed , instead of suggesting ( IMO incorrectly ) that it ’s impossible . Originally posted by in 
 To be clear , this was in reference to text that mentioned that certain frames could n't be sent in 0 - RTT . That would only be true if we made this a requirement . 
 This actually is already addressed in the TLS draft , as pointed out in another thread : , " Though an endpoint might retain older keys , new data MUST be sent at the highest currently - available encryption level . " If you have 1 - RTT keys , you MUST use them . There 's currently no server verification that you do so , however . 
 I think this should be stated in transport as well as TLS , along with a statement that a server MAY / SHOULD / MUST ignore  packets that have higher packet numbers than the first received 1RTT packet . The first is editorial I believe , the latter is borderline design . If we decided it was valid to close the connection if a 0RTT packet was received with a higher packet number than 1RTT , then that 's definitely not editorial , but I think it may be a good way to enforce proper behavior . 
 Agreed . I think that this should be a MAY / SHOULD close the connection with PROTOCOL_VIOLATION rather than " ignore " , because that aligns the handling with how we agreed to handle other misuse of 0 - RTT packets ( see ) . 
 said it right at the  : this is a key update scenario , from 0 - RTT to 1 - RTT key . Treat it the same way as peer continuing using old key after key update . 
 I think the only verifiable requirement is " must not ack 1RTT packet in 0RTT packet " . The server can definitely detect that , and send a connection close with reason PROTOCOL VIOLATION when it happens . This would effectively force the client to switch to 1RTT soon . 
 exceeding the initial flow control /  streams from the remembered TP 's is also detectable . 
 detection with flow control would require special case code in stream processing , as in " check against the current window but if 0 - RTT check against the initial window " . Could be done , but that would be another wart . Also , in many cases the 0 - RTT data sent is well below the initial flow control window , so it will not be a very efficient test . 
 It 's actually something that can be implemented in a clear and concise way . The only thing you need to have are objects representing limits for each type of packets . When processing 0 - RTT packets , the logic would refer to the limits declared by TP of the previous connection . When processing 1 - RTT packets , the logic would refer to the limits declared by current  and the  frames . 
 In , we discuss what can be sent in 0 - RTT . We realized that while in theory the client should not be accepting 1 - RTT packets from the server and then sending 0 - RTT , there is nothing to prevent that . The proposed defense is to prohibit the client from using increased limits ( on flow control or streams ) that it might have learned from 1 - RTT packets . This ensures that 0 - RTT - the parts of the connection that might be replayed - are strictly limited to the initial limits . Like many other things , we would require the client not to exceed this limits and merely allow the server to enforce that , in case the server was not inclined to do so . 
 : +1 : 
 Tokyo conclusion : we will prohibit the client from sending more than the remembered flow control limits ( nothing from the new transport parameters or 1 - RTT packets can be used to increase the window ) . Some debate about requiring servers to enforce this requirement , decided not to require the generation of a connection error , but to recommend that servers include the check . 
 Discussed in Prague ; believe it 's a dup of . 
 is the " proposal " here that it 's a dup ? 
 closes this issue . It 's a different variation , but a single solution . 
 LGTM modulo below . Other than thinking our enforcement guidance should be a bit stronger , I think this is okay . It expresses the correct principles . Yup , this LGTM.Still LGTM
Paragraph (version B):
To entities other than its intended recipient, a stateless reset will
be appear to be a packet with a short header.  For the packet to
appear as valid, the Unpredictable Bits field needs to include at
least 182 bits of data (or 23 bytes, less the two fixed bits).  This
is intended to allow for a Destination Connection ID of the maximum
length permitted, with a minimal packet number, and payload.  The
Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD.  More unpredictable bytes might be necessary
if the endpoint could have negotiated a packet protection scheme with
a larger minimum AEAD expansion.
Paragraph (version B):
A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer.  The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame.  The "ack_delay_exponent" defaults
to 3, or a multiplier of 8 (see transport-parameter-definitions).
Scaling in this fashion allows for a larger range of values with a
shorter encoding at the cost of lower resolution.