Draft: draft-ietf-quic-transport

Commentary: Fixes issue 
 This is right . I think that we got a bit of skew over time and the text you cut no longer makes sense . 
 ( was on the mailing list . ) PR introduces the following text : The problem with the " server MAY proceed " part is that there is no reasonable way for the server to do so . If ODCID can not be extracted from the invalid Retry token , then the server can not set the , which it MUST do . The recommendation that the " server MAY proceed " should come out . 
 I am not sure if I agree . IIUC , the sentence suggests that a server can process the Initial packet and proceed the handshake as if that Initial packet did not have a token attached . That 's at least possible technically ( we do that occasionally for NEW_TOKEN tokens , right ? ) . Whether if people would want to do that is a different question , but I think this behavior makes sense for deployments in which you 'd have a retry middlebox occasionally installed ( and uninstalled ) . 
 The problem here is that something that is identifiable as a Retry token as distinct from a NEWTOKEN token will ultimately not be usable . There 's a bit of hedging necessary though as junk that appears to be a Retry token is still ultimately just junk . To be concrete , let 's say that you generate Retry tokens that start with " RETRY ! ! ! " and  tokens start with " ~~~NEW_TOKEN " The difference between those two is such that it would be unlikely for corruption to cause one to be mistaken for the other , and you have a way to distinguish the two even when all the subsequent bits ca n't be interpreted after you lose keys or something like that . 
 The only case in which the server can proceed is when the server sees a junk token , but knows that the client does not consider it a Retry token . There 's no mechanism for the client to tell the server what it thinks the token it has presented is , so the server does n't know when it 's in this state . I agree -- axe it . 
 As pointed out by and the client would reject the handshake even if the server ignores the token and proceeds with the handshake . This is because TP.originalconnectionid would not contain the expected value . I now agree that this MAY is awkward and that we can strike the sentence . 
 The resolution to send  error could be used to attack tokens through timing attacks . It may be better to drop the packet or to require some attack mitigation measure .
Paragraph (version A):
If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept
another Retry token.  The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client.  A server MAY
proceed with the connection without verifying the token, though the
server MUST NOT consider the client address validated.  If a server
chooses not to proceed with the handshake, it SHOULD immediately
close (immediate-close) the connection with an INVALID_TOKEN error.
Note that a server has not established any state for the connection
at this point and so does not enter the closing period.
Paragraph (version B):
If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept
another Retry token.  The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client.  Instead, the
server SHOULD immediately close (immediate-close) the connection with
an INVALID_TOKEN error.  Note that a server has not established any
state for the connection at this point and so does not enter the
closing period.