Draft: draft-ietf-quic-transport

Commentary: This came up as the result of an incomplete implementation , but there are - maybe - good reasons to have the same stateless reset token being used for multiple connection IDs on the same connection . There are drawbacks however . Reuse of a stateless reset token means that you have to remember ( and consistently route ) connection IDs , even when they are retired . This text makes a note of the possibility and explains the drawbacks . 
 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 . 
 We hit this during interop , where one implementation would re - issue the same SRT(Stateless   ) it included in the TPs in each new NEWCONNECTIONID frame . The question was raised whether that was allowed or not , and decided that " design text was needed . " 
 LGTM . Quicly was originally implemented this way , though we stopped doing that in the CID generation scheme that we use as the default . When an endpoint constructs a CID as an encrypted tuple of ( connid < sup1</sup , pathid ) , there 's no need to regenerate a token for every new path ID being generated . 1 : An ID that identifies a QUIC connection . Not the CID that appears on the wire .
Paragraph (version A):
Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once.  This method for
choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the
same static key (see reset-oracle).  A connection ID from a
connection that is reset by revealing the Stateless Reset Token MUST
NOT be reused for new connections at nodes that share a static key.
Paragraph (version B):
Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once.  This method for
choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the
same static key; see reset-oracle.  A connection ID from a connection
that is reset by revealing the Stateless Reset Token MUST NOT be
reused for new connections at nodes that share a static key.
Paragraph (version B):
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.