Draft: draft-ietf-quic-transport

Commentary: As agreed in London and Tokyo . 
 We already have an editorial issue in this section ; it needs breaking into subsections rather than combining long paragraphs into even longer ones . Thanks for catching the packet number thing . 
 I 've been trying to reason about Retry and in particular the following text : This seems like it really is saying that a Retry is a new connection , and in particular that the server can not memorize the CRYPTO from the previous Initial ( which it might otherwise choose to do ) . I 'm still trying to figure out if this is the right answer , but it seems confusing to allow the client to have both behaviors , especially as we encourage the " construct a new one " . Also , if you construct a new one , could you potentially reuse the KeyShare values ( might be an issue with PQ ) . I 'm not quite sure what I think about this , but I wanted to post an issue to see if other people think it 's weird and if so , maybe we should take a more prescriptive stance . 
 I think that it 's OK to resend the same cryptographic handshake message . The semantics of Retry mean that the first was n't used . The only thing that might be a concern is if an attacker can use this to cause two parallel connections to be established from the same ClientHello . I do n't think that 's possible , and the protocol is structured in a way that avoids that . ( Your point about reuse and PQ does make me think that the stuff was contemplating as a defense against packet injection is potentially dangerous in that context . I 'm glad that there are now other approaches being contemplated for that . ) 
 It is the same connection . Otherwise , the originalconnectionid transport parameter has no clear meaning . 
 What says makes sense . We may want to tease out the text a bit to articulate this point , but I think it 's part of the same connection establishment and therefore part of the same connection . 
 Tokyo conclusion : It 's the same connection . We will prohibit changing the cryptographic handshake message based on receiving Retry . You can think of this as re - sending a lost Initial . 
 Not quite , since a retry has a fixed target DCID ( stateful ) whereas a lost initial has a random OCID that can reach a random server ( stateless ) 
 IIUC , we are going to require the Hello to be the same and to not reset the PN when receiving a Retry . Assuming that is true , do we need to keep the statement that says that the server CID " MUST not be equal to the Destination Connection ID field of the packet sent by the client " ? I think we can remove it now ( for simplicity ) . See also : 
 that requirement also exists to ensure that the server does n't fake out the ODCID transport parameter . I think we 're should keep that bit . 
 Ah thank you for pointing out that . Agreed . 
 London discussion : to include the last editorial bits in the spec 
 LGTM modulo the point below .
Paragraph (version A):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see negotiating-connection-ids).
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client can
either reuse the cryptographic handshake message or construct a new
one at its discretion.
Paragraph (version A):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.  A client
that sends additional 0-RTT packets without constructing a new
cryptographic handshake message MUST NOT reset the packet number to 0
after a Retry packet; see packet-0rtt.
Paragraph (version B):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see negotiating-connection-ids).
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it includes in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version B):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.  A client
MUST NOT change the cryptographic handshake message it sends in
response to receiving a Retry.
Paragraph (version B):
A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; packet-0rtt contains more
information on this.