Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



> @@ -2721,6 +2724,96 @@ between endpoints.  Application protocols SHOULD define rules for handling
 streams that are prematurely cancelled by either endpoint.
 
 
+# Seeding {#seeding}
+
+In order to avoid ossification of the cleartext and obfuscated fields of QUIC
+packets, a server can announce a set of alternative initial values to be used,
+which is comprised of:
+
+* Version number; a 32-bit unsigned number that is to be presented on wire in
+  place of the version number specified in this document.  This value MUST NOT
+  be a reserved version ({{versions}}).
+
+* Packet type modifier; a two-bit value that obfuscates the Long Packet Type of
+  a long header packet ({{long-header}}).  The long packet type bits of a long
+  header packet is encoded as an bti-wise exclusive or (XOR) of the packet type

```suggestion
  header packet is encoded as an bit-wise exclusive or (XOR) of the packet type
```

> +
+The rest of this section applies to the servers that advertise non-default
+values as their seeds.
+
+
+## Server Behavior
+
+Typically, a server that advertises the alternative seeds would act in the
+following steps:
+
+* The server pre-allocates a set of unused version numbers as the alternative
+  version numbers, associating each of those version numbers with a packet type
+  modifier chosen at random.
+
+* When issuing a NEW_TOKEN token, the server generates the alternative initial
+  salt by calling a pseudo-random function.  Then it builds a token that

There is no need to use a pseudo-random function if the server has access to better randomness (but to be fair this is for a typical implementation). I would just say it generates a cryptographically secure random number.

> +values as their seeds.
+
+
+## Server Behavior
+
+Typically, a server that advertises the alternative seeds would act in the
+following steps:
+
+* The server pre-allocates a set of unused version numbers as the alternative
+  version numbers, associating each of those version numbers with a packet type
+  modifier chosen at random.
+
+* When issuing a NEW_TOKEN token, the server generates the alternative initial
+  salt by calling a pseudo-random function.  Then it builds a token that
+  embeds the alternative seeds including the initial salt being generated.  The
+  token will be encrypted using a key known only to the server, thereby

```suggestion
  token will be encrypted using a key known only to the server, or server cluster, thereby
```

> +## Server Behavior
+
+Typically, a server that advertises the alternative seeds would act in the
+following steps:
+
+* The server pre-allocates a set of unused version numbers as the alternative
+  version numbers, associating each of those version numbers with a packet type
+  modifier chosen at random.
+
+* When issuing a NEW_TOKEN token, the server generates the alternative initial
+  salt by calling a pseudo-random function.  Then it builds a token that
+  embeds the alternative seeds including the initial salt being generated.  The
+  token will be encrypted using a key known only to the server, thereby
+  conforming to the requirements in {{validate-future}}. After that, the server
+  sends a NEW_TOKEN frame that contains the generated token and the seeds that
+  have been embedded to that token.

```suggestion
  have been embedded into that token.
```

> +  have been embedded to that token.
+
+* When the client reconnects to the server by using the provided token and the
+  seeds, the server first checks if the version number field of the incoming
+  packet contains one of the alternative version numbers it advertises, then if
+  that is the case, applies the corresponding packet type modifier to recover
+  the correct packet type.  If the recovered packet type is an Initial packet
+  and that packet contains a NEW_TOKEN token, the server decrypts the embedded
+  token and recovers the initial salt, uses that to decrypt the payload of the
+  Initial packet.
+
+* When sending a Retry in response to an Initial packet carrying an alternative
+  version number, the server embeds the NEW_TOKEN token found in the Initial
+  packet within the retry token it issues.  Once the server receives a response
+  from the client carrying that retry token and the path is validated, it
+  decrypts the NEW_TOKEN token embedded in the retry token to recover the

```suggestion
  decrypts the NEW_TOKEN token embedded within the retry token to recover the
```

> +  packet contains one of the alternative version numbers it advertises, then if
+  that is the case, applies the corresponding packet type modifier to recover
+  the correct packet type.  If the recovered packet type is an Initial packet
+  and that packet contains a NEW_TOKEN token, the server decrypts the embedded
+  token and recovers the initial salt, uses that to decrypt the payload of the
+  Initial packet.
+
+* When sending a Retry in response to an Initial packet carrying an alternative
+  version number, the server embeds the NEW_TOKEN token found in the Initial
+  packet within the retry token it issues.  Once the server receives a response
+  from the client carrying that retry token and the path is validated, it
+  decrypts the NEW_TOKEN token embedded in the retry token to recover the
+  alternative initial salt that is to be used for unprotecting the packet
+  payload.
+
+Instead of associating a new alternative initial salt to every NEW_TOKEN token,

```suggestion
Instead of associating a new alternative initial salt with every NEW_TOKEN token,
```

> +* When sending a Retry in response to an Initial packet carrying an alternative
+  version number, the server embeds the NEW_TOKEN token found in the Initial
+  packet within the retry token it issues.  Once the server receives a response
+  from the client carrying that retry token and the path is validated, it
+  decrypts the NEW_TOKEN token embedded in the retry token to recover the
+  alternative initial salt that is to be used for unprotecting the packet
+  payload.
+
+Instead of associating a new alternative initial salt to every NEW_TOKEN token,
+a server might map a fixed salt to each of the alternative version numbers it
+issues.  Such design is not recommended, as an active attacker might build a
+list of known alternative version numbers and their initial salts and use that
+list to decrypt the payload of Initial packets using those alternative version
+numbers.  But still, having a set of version numbers and initial salts used
+concurrently is considered better than just using the default values of QUIC in
+terms of preventing ossification.

I am not comfortable with the slack given here. While it does improve things when salt is reused, it also gives the client a false sense of security. It would be better if the client could be certain that it does indeed sent private information on the wire.

For example it might create an initial connection to bootstrap safety, similar to if it connected to a secure DNS with crypto keys (TBD), and then reconnects to send confidential informational information. 

Taking this one further, it would be advantageous if a token could be used across different server certificates so the initial certificate could be "harmless" in order to enhance privacy.

> +issues.  Such design is not recommended, as an active attacker might build a
+list of known alternative version numbers and their initial salts and use that
+list to decrypt the payload of Initial packets using those alternative version
+numbers.  But still, having a set of version numbers and initial salts used
+concurrently is considered better than just using the default values of QUIC in
+terms of preventing ossification.
+
+A server MUST NOT send a Version Negotitation packet in response to a long
+header packet with an alternative version number it has advertised.
+
+
+## Distributing the Seeds
+
+This specification defines how the seeds are used as well as how they are
+advertised using a NEW_TOKEN frame.  Other specifications MAY define other
+methods for distributing or deducing these seeds.

What are "other specifications"? Another QUIC version?

> @@ -2721,6 +2724,96 @@ between endpoints.  Application protocols SHOULD define rules for handling
 streams that are prematurely cancelled by either endpoint.
 
 
+# Seeding {#seeding}
+
+In order to avoid ossification of the cleartext and obfuscated fields of QUIC
+packets, a server can announce a set of alternative initial values to be used,
+which is comprised of:
+
+* Version number; a 32-bit unsigned number that is to be presented on wire in
+  place of the version number specified in this document.  This value MUST NOT
+  be a reserved version ({{versions}}).

It is not very clear from this text if the intention is to generate a new representation of the same version in which the token was generated, or there is indeed a new version. Since this does not cover version negotiation, it presumably refers to the same version. But that could change as versions get added and perhaps V1 should be prepared for that (I'm not sure I am getting this right). @MikeBishop alluded to something similar in an earlier comment AFAIR.

-- 
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/3166#pullrequestreview-309698002