How should endpoints react to differences between long header version and chosen version

[David Schinazi]

In quicwg/version-negotiation#129, @anrossi points out two scenarios where endpoint handling isn't clear:

• Scenario 1:

  • A QUIC server receives an INITIAL where LongHeaderVersion=v1 and ChosenVersion=v2

• Questions for scenario 1:

  • Should the server close the connection?
  • If so, what error should the server use?
  • Or should the server ignore the long header versions?
  • Same question if v1 and v2 are inverted.

• Scenario 2:

  • Client sends a QUICv1 INITIAL with ChosenVersion=v1 and OtherVersions=v1,v2
  • Client receives server reply HANDSHAKE where LongHeaderVersion=v1 and ChosenVersion=v2

• Questions for scenario 2:

  • Should the client close the connection?
  • If so, what error should the client use?
  • Or should the client ignore the long header versions?
  • Same question if v1 and v2 are inverted.

[Anthony Rossi]

For scenario 1:

• The server should close the connection because the transport parameter does not match the header, which might indicate tampering with the packet header (maybe by a pesky middlebox)
• Since this occurs during parsing of the transport parameters, using the transport parameter error makes sense to me. However, it could also be argued that since it's the version negotiation transport parameter, that the version negotiation error should be used instead.
• Server ignoring the header version is a bold move, and it removes one vector for bad actors to force QUIC connections to fail, but it also removes a way for the server to detect interference with the connection. If the course of QUIC is to move away from using/trusting the long header version field, then this would be a strong step in that direction.
• I think all I've said above still applies when the versions are reversed.

In scenario 2:
Aren't the server's transport parameters encrypted with the HANDSHAKE keys instead of INITIAL? So, the INITIAL packet with LongHeaderVersion=v1 wouldn't matter until the client processed the HANDSHAKE LongHeaderVersion?

[David Schinazi]

For scenario 1:

I agree with you on all points. When it comes to which error, I don't much care which one it is, but we should pick one and specify it.

In scenario 2: Aren't the server's transport parameters encrypted with the HANDSHAKE keys instead of INITIAL? So, the INITIAL packet with LongHeaderVersion=v1 wouldn't matter until the client processed the HANDSHAKE LongHeaderVersion?

You're right, I've edited my comment above to mention HANDSHAKE instead of INITIAL for that packet

[Martin Duke]

I have some text ready, but am waiting to see what the v1 draft specifies when long_header = v1 and chosen_version = unknown.

[David Schinazi]

Agreed: let's wait to see how we resolve quicwg/version-negotiation#129 before merging anything here.

[Martin Duke]

quicwg/version-negotiation#129 essentially solves this issue, but #78 is relevant to close the loop in the v2 draft. Closing this one.