Draft: draft-ietf-quic-transport

Commentary: This forbids the use of duplicate stateless reset tokens . It also cleans up some of the related language about matching of tokens . . 
 What next steps should be taken here ? Is this ready for a consensus call ? 
 : I expect that the chairs will put out a consensus call soon . 
 As part of the discussions on / , we 've found that reusing stateless reset tokens ( SRTs ) can allow attackers that delay packets to close connections . Even though the text in does a good job explaining why you should n't reuse SRTs , I do n't see any reason why one would want to reuse SRTs across connection IDs in the same connection . Therefore I would prefer we ban reusing them , and make it a PROTOCOL_VIOLATION to do so . Apologies for not raising this on , I had not thought about the problem at that time . 
 I do not think you missed anything . Instead , you spotted the issue at the exact moment ; it 's my understanding that is introducing this issue . There is no problem in the current design , because receiving a packet with an outdated CID is not expected to cause a stateless reset . Regarding why you 'd want to reuse a SRT , the simple reason is because you do not need to create different SRTs for every Connection ID . A QUIC stack that generates a CID by a construction like < sup1</supcan use as a construction for generating SRT . For QUIC stacks that are n't interested in retiring CIDs ( which seems to be the majority for me ) , this construction makes sense . I think my preference would be to retain the design ; it 's just about adding a warning when you want to retire a CID . 1 : path_index is a sequence number of path for each connection 
 I do n't think introduces this issue . It does make it worse but the issue was already present . It 's reasonable for a server implementation to drop a CID from their state when the client retires it . There are two options to guarantee safety : sure each CID has a distinct SRT sure once a CID is sent in NEWCONNECTIONID it always routes back to this connection I think ( 1 ) is simpler and giving implementations two options here not only makes the spec more complicated , but can also lead to accidental vulnerabilities . I think it would be safer for the implementations you mention to use to generate their SRT . That also makes it simpler to generate the SRT from the cleartext CID . In general , it 's been this spec philosophy to add constraints that can be verified by the peer whenever possible . Forcing distinct CIDs ensures verifiable security whereas requiring that CIDs get routed appropriately for the duration of the connection is not enforceable and therefore easier to get wrong . 
 Essentially , the current text says that an issuer ca n't actually forget a retired CID until all CIDs with the same SRT have been retired . At that point and not before , you can forget all of them at once . does n't change this at all -- does n't even really make it worse . That PR provides a mechanism for asking a client to retire a certain set of CIDs ; if the set only partially overlaps with the set of CIDs covered by an SRT , that mechanism is not terribly useful because you ca n't actually forget all the CIDs you asked the peer to retire . It could be very useful to ask the peer to retire the last CID in one of these groups because you 've got 200 of them you 'd really like to clear out . But that does n't change the core fact : An issuer ca n't actually forget a retired CID until all CIDs with the same SRT have been retired . If each SRT maps uniquely to a CID , this is a simple requirement to satisfy . If you choose to do something else , that 's your problem . 
 I think what says is correct . OTOH , I now think that forbidding reuse of SRT might help the receiver of the stateless resets . Without the prohibition , when retiring a CID , an endpoint needs to consult other SRTs that have been issued for the same connection to see if it can unregister the SRT corresponding to the CID being retired , or use a ref - counted hashmap for maintaining the mapping from SRTs to connections . We might argue that this requirement is easy to miss , and hard to test . Having the prohibition removes this requirement and therefore can be considered as a simplification . Contrary to that , we might argue that allowing the reuse of SRT has marginal benefit . It is trivial to construct different SRT for each CID , as pointed out by 
 analysis is entirely correct . I do n't think that we should put in rules to prevent self - harm through idiocy . And this is definitely a case of that . An endpoint that forgets a CID when the associated SRT is active only hurts themselves . The text is sufficient as it stands . A prohibition wo n't prevent implementations from doing dangerous things . As it stands , you need to take extraordinary steps to put yourself in position to mess this up . The construction describes is a totally sensible one , but it is very hard to forget connection IDs with that scheme . More relevant to this , the SRT construction process described in the spec wo n't have this problem . What exactly do you think this prohibition will achieve ? 
 If there is a prohibition , an endpoint can remove the SRT of the CID being retired , without consulting the SRTs of other CIDs belonging to the same connection . While incorrect in terms of current spec , such design works flawlessly with endpoints that issue different SRT for each CID . It seems that most implementations would issue different SRT for each CID . Then , there 's chance that we might see stacks implementing this incorrect but simpler approach . Having the prohibition eliminates the chance of seeing these " incorrectness . " 
 I agree that we should remove the text that allows the reuse of SRTs from the spec ( In fact , last night I was planning to open exactly this issue , and woke up this morning to see that already did so while I was asleep ) . I do n’t see any reason why you ’d want to reuse a SRT in the first place - computing one HMAC should n’t be more expensive than applying the packe protection to send a single packet . With regards to how you store connection IDS , this design is only simpler if you do the wrong thing and don‘t keep track of expired connection IDs that still have active SRTs . Doing it the right way will most likely result in a more complex design than associating each CID with its own SRT . In short : it ’s easy to mess up , and there ’s little benefit , so let ’s remove it . 
 I 'm not totally against a unique SRT per CID , but I am concerned about the static memory use of otherwise passive connections . If a CID and SRT can be 255 bytes each ( depending on where discussions go ) that is half a kilobyte per CID , and there might be 8 of those , possibly more . That is 4 K per connection even if you retire all active buffers because there is n't currently any traffic . 
 SRTs are 16 bytes long 
 I 'm not sure about that - is n't there text about hiding SRT among ordinary traffic . If so it can not be shorter than the CID + overhead , well the packet that is . But I 'm probably mixing up packet size with storage requirements . 
 The SRT is only 16 bytes , but the packet it 's sent in is supposed to look like a typical QUIC short header packet , and therefore needs to be of a minimum size . 
 So essentially , we 're saying that we maybe did n't really have consensus on the answer to being " yes . " But since there was a consensus call that said we did , now the question is whether we have consensus to reverse that decision . Let me suggest that be taken to the list . 
 Discussed in Montreal , next step is for to do a PR and follow normal process 
 Conclusion : prohibit the use of duplicate tokens . Allow , but not require the use of PROTOCOL_VIOLATION if a duplicate is detected . 
 covered this . 
 The current text does not explicitly say that endpoint has to check the stateless reset token received in NEWCONNECTIONID ( and server 's TP if endpoint is a client ) . then compare the last 16 bytes of the packet with all Stateless   that are associated with connection IDs that are currently in use . This includes Stateless   from NEWCONNECTIONID frames and the server 's transport parameters . With this wording , I was under the impression that server can use stateless reset token in its own TP , but it seems not . I think it would be nice to state that only received stateless reset tokens are checked . 
 carried in the NEWCONNECTIONID frame sent by either peer , and servers can specify the statelessresettoken transport parameter during the handshake ( clients can not because their transport parameters do n't have confidentiality protection ) . This text is also problematic because it suggests that endpoint can specify token sent by either peer . 
 The first of these is already addressed in the draft , though it could be improved .
Paragraph (version A):
To support this process, a token is sent by endpoints.  The token is
carried in the NEW_CONNECTION_ID frame sent by either peer, and
servers can specify the stateless_reset_token transport parameter
during the handshake (clients cannot because their transport
parameters don't have confidentiality protection).  This value is
protected by encryption, so only client and server know this value.
Tokens are invalidated when their associated connection ID is retired
via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id).
Paragraph (version B):
To support this process, a token is sent by endpoints.  The token is
carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
frame.  Servers can also specify a stateless_reset_token transport
parameter during the handshake that applies to the connection ID that
it selected during the handshake; clients cannot use this transport
parameter because their transport parameters don't have
confidentiality protection.  These tokens are protected by
encryption, so only client and server know their value.  Tokens are
invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (frame-retire-connection-id).
Paragraph (version A):
An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet.  The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset
Tokens that are associated with connection IDs that the endpoint
recently used to send packets from the IP address and port on which
the datagram is received.  This includes Stateless Reset Tokens from
NEW_CONNECTION_ID frames and the server's transport parameters.  An
endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have
been retired.
Paragraph (version B):
An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet.  The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset
Tokens corresponding to active connection IDs that the endpoint has
used for sending packets to the IP address and port on which the
datagram is received.  This includes Stateless Reset Tokens from
NEW_CONNECTION_ID frames and the server's transport parameters.  An
endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have
been retired.
Paragraph (version A):
The same Stateless Reset Token MAY be used for multiple connection
IDs on the same connection.  However, reuse of a Stateless Reset
Token might expose an endpoint to denial of service if associated
connection IDs are forgotten while the associated token is still
active at a peer.  An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the
connection ID has been retired.  Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in reset-oracle.
Paragraph (version B):
The same Stateless Reset Token MUST NOT be used for multiple
connection IDs.  Endpoints are not required to compare new values
against all previous values, but a duplicate value MAY be treated as
a connection error of type PROTOCOL_VIOLATION.