Re: [quicwg/base-drafts] Rework Retry packet (#1498)

[Christian Huitema <[e-mail]>]

huitema approved this pull request.

I like these changes. Can we adopt them as baseline for the 7th interop? The retry mechanism of draft-13 is pretty hard to implement without those.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~
 

Unless I am missing something, len(token_length) is only available *after* the PN has been decrypted.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~
 

So we have a circular dependency when decrypting. See issue #1535.

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #retry-format title="Retry Packet"}
+
+A Retry packet (shown in {{retry-format}}) only uses the invariant portion of
+the long packet header {{QUIC-INVARIANTS}}; that is, the fields up to and
+including the Destination and Source Connection ID fields.  The contents of the
+Retry packet are not protected.  Like Version Negotiation, a Retry packet
+contains the long header including the connection IDs, but omits the Length,
+Packet Number, and Payload fields.  These are replaced with:
+
+ODCIL:
+
+: The length of the Original Destination Connection ID field as an unsigned
+  8-bit integer.  This field does not use the same encoding as the DCIL and SCIL
+  fields.

I agree with @janaiyengar. Having the same encoding would remove error conditions such as 1<=ODCIL<=3, or ODCIL>18. But of course it would introduce the error "(ODCIL&0xF0)!=0". So maybe it is a wash.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~
 

My bad. This is actually addressed later, as the token has now moved in front of the PN.

>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Token (*)                        ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           Length (i)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                     Packet Number (8/16/32)                   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                          Payload (*)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Yes. This new design solves issue #1535.

>  
-If the client has a suitable token available from a previous connection, it
-SHOULD populate the Token field.
+If the client has a token received in a NEW_TOKEN frame on a previous connection
+to what it believes to be the same server, it can include that value in the
+Token field of its Initial packet.
+
+A client SHOULD NOT reuse a token.  Reusing a token on different network paths
+would allow activity to be linked between paths (see {{migration-linkability}}).
+A client MUST NOT reuse a token if it believes that its point of network

@janaiyengar , no, this is not too strong. There is a real privacy risk to reusing tokens in different contexts. This is pretty similar to the privacy issues with TCP Fast Open, or with TLS resume. Encryption of New Token provides protection against on path elements, but it does not provide protection against the server itself.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498#pullrequestreview-135240081