Specify Version Negotiation after Crypto Failure

[huitema]

During the recent interop tests, we have seen a number of version negotiation failures, which goes like that:

1. Client sends packet with a test version number, e.g., 1a1a1a1a. Content of packet is encrypted with
   some version dependent "cleartext key" -- note the same a specified in draft-08.
2. Server receives packet, and fails to decrypt the content.
3. Server thus ignores the packet. No version negotiation.

The TLS spec seems unambiguous:

The salt value is a 20 octet sequence shown in the figure in hexadecimal notation. Future
versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different
for each version of QUIC. This prevents a middlebox that only recognizes one version of QUIC
from seeing or modifying the contents of handshake packets from future versions.

Yet, several implementations missed that. Is the spec clear enough?

[MikeBishop]

In theory, you can't hit a crypto failure -- if the version is unknown, you have no data about what packet protection might have been used on the payload, let alone key selection. If the version number is unknown, you have no reference point to interpret any field outside the invariants.

[huitema]

@MikeBishop yes, you are right in theory. But in practice I just tested that two implementations out of 10 got it wrong, so I suspect we need to be a bit more explicit.

[MikeBishop]

Section 7.2.1 seems to already discuss this. It sounds like the problem is that people are jumping directly to decrypting and missing the discussion of determining whether the version is appropriate. I think Section 7 is evolving in a direction of an overall "how to process incoming packets" flowchart -- maybe that's the needed clarification.

[martinthomson]

@huitema, do you think that the new text in Section 7.1 helps here? If not, perhaps you could recommend some text to add (and the appropriate location for that text).

[huitema]

Section 7.1.2 says: If a server receives a packet that has an unsupported version and sufficient length to be an Initial packet for some version supported by the server, it SHOULD send a Version Negotiation packet as described in Section 7.2.1. Servers MAY rate control these packets to avoid storms of Version Negotiation packets.

That's good, but I would add a specific caveat. "Packets from different versions may use different parameters when computing clear text packet protection per [some appropriate ref to the TLS draft]. Servers who do not support a particular version will not be able to decrypt the content of the packet. They still SHOULD send a Version Negotiation packet, as long as the message has a sufficient length."