Draft: draft-ietf-quic-transport

Commentary: … are : require unlinkability by stating : " SHOULD NOT expose linkability " suggest use of encryption when embedding expiration time in the token 
 Thanks ! 
 My understanding is that tokens provided by NEW_TOKEN frames should not leak information that allows observers correlate the newly established connection with the previous connection . Such information include the time when the token was issued , RTT , server name ( when SNI is not used or Encrypted SNI is used ) , or even the size of the token . However , the draft seems to be vague about the requirement . I think it might be worth clarifying the principle in the draft . " a token SHOULD include an expiration time " ( section 8.1.2 ) - I think we should change this to " a token SHOULD be associated an expiration time " , considering the fact that we are talking about " stateful " design ( stateless design is mentioned briefly in one of the following paragraphs ) . In a stateful design , an opaque identifier is the only thing that a server should be allowed to send . " In a stateless design , a server can use encrypted and authenticated tokens to pass information to clients " - I think we might prefer using " SHOULD " rather than " can " . 
 I think the current text is fine : " include " translates to " put into the token and encrypt " in my mind . Reading that a token is " associated " with an expiration time would give me pause . 
 Would you mind clarifying where the " and encrypt " comes from ? My point is that that is the way it should be , however the text does not seem to clarify that . 
 I do n't recall how I arrived at it -- perhaps some common sense . Now that I have implemented it , it seems only natural . Perhaps we should simply add " and encrypt " to the text instead of changing to " associated with , " which is less clear ? 
 I 'm happy to know that we share the common sense : +1 : As stated in the opening comment , my " editorial " preference goes to stating the principle that any information in an NEW_TOKEN token ( other than the opaque lookup key used in a stateful design ) SHOULD be encrypted . If that is to be met , I think adding " and encrypt " would be fine . 
 I agree with -- I think stating this explicitly as a SHOULD is sensible . 
 ( For the chairs , and triage purposes ) . This suggests a normative requirement that I do n't think that we need , or that is already implied by existing text . There would be new normative text . I believe that is still editorial on the basis that the requirement is already implied , but will defer to your judgment . 
 FWIW , what I am shooting for is a change like 
 and others , is kazuho kind of the change you were envisioning ? 
 I was asked to move here . I miss the point , that the server SHOULD NOT construct the same token multiple times because this leads to additional scenarios where tracking by a network observer becomes feasible . The referenced PR does not fix this problem . 
 I think we are in agreement that unlinkability between tokens is required . IMO the phrase " SHOULD NOT expose linkability " in the proposed text captures the concept , though I might agree that " i.e. , ... " needs improvement . 
 change would be adequate , and I agree with that this is effectively editorial . Do the chairs want to mark this issue as ? 
 Yes , I agree with you on the phrase " Should NOT expose likability " . To address my concern , I suggest to include " This includes that the server constructs each time a different token when issuing tokens to clients from the same source address . " after line 1560 of # kazuho / base - drafts 
 Marking this as editorial 
 Looks good , modulo the minor suggestions .
Paragraph (version A):
Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is
subsequently used.  Thus, a token SHOULD include an expiration time.
The server MAY include either an explicit expiration time or an
issued timestamp and dynamically calculate the expiration time.  It
is also unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to
be successful.
Paragraph (version B):
The token MUST NOT include information that would allow it to be
linked by an on-path observer to the connection on which it was
issued.  For example, it cannot include the connection ID or
addressing information unless the values are encrypted.
Paragraph (version B):
Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is
subsequently used.  Thus, a token SHOULD have an expiration time,
which could be either an explicit expiration time or an issued
timestamp that can be used to dynamically calculate the expiration
time.  A server can store the expiration time or include it in an
encrypted form in the token.
Paragraph (version B):
It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to
be successful.