Subject: [quicwg/base-drafts] Versions in transport parameter force reformatting client hello on renegotiation (#710)

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Aug 2017 21:53:05 +0000 (UTC)

The transport parameter extension sent in the Client Hello includes the following:

>      select (Handshake.msg_type) {
>         case client_hello:
>            QuicVersion negotiated_version;
>            QuicVersion initial_version;
>            ...

This is annoying, since the "negotiated version" will not be known until negotiation is complete. As the extension is sent in the first flight with the Client Hello, this means that the value of this Client Hello will change between the first Client Initial packet that triggered a version negotiation, and the repeated Client Initial packet that is sent with the new version number. The text in section 7.1 says:

> Though the contents of a packet might not change in response to version negotiation, a client MUST increase the packet number it uses on every packet it sends. 

If we keep the "negotiated version" in the transport parameter extension, the content of the packet will always change, so this sentence is misleading.

I would prefer to only include the "initial version" in the transport parameter extension. The server can detect shenanigans if the initial version belong to its supported version list, yet is different from the version in the QUIC header. The client can detect shenanigans if the server supported list includes its own initial proposal.

There is an argument that the QUIC header might be forged. In that case, it seems better to include the negotiated version in the server parameters, before the list of supported versions, and trust the client to detect any disparity.

-- 
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/issues/710

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Aug 2017 23:22:20 +0000 (UTC)

Taking the negotiated version out removes it from the integrity check over the handshake.  That would be unfortunate.

-- 
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/issues/710#issuecomment-320539481

---

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Aug 2017 22:00:33 -0700

Yes, that's why I was suggesting adding it to the server extension. That way the Client Hello can be repeated with just a change of the version number and sequence numbers in the QUIC header, and the Server Hello needs to be formatted only once.  The new structure would be:

    struct {

         case encrypted_extensions:
            QuicVersion negotiated_version;
            QuicVersion supported_versions<2..2^8-4>;

         case new_session_ticket:
            struct {};
      };
      TransportParameter parameters<30..2^16-1>;
   } TransportParameters;

-- 
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/issues/710#issuecomment-320569099

---

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Aug 2017 22:07:54 -0700

The current spec does not work well for a client that treats TLS as a black box. With the current spec, it does something like:

 * Initiate TLS Context, format extension, obtain Client Hello message
 * Send Client Hello message on stream zero in client initial packet
 * On receiving version negotiation packet, select new version.
 * Delete old TLS context, initiate new one, format new extension, obtain new Client hello.
 * Clean up stream zero, send new Client Hello message on new stream 0 in new client initial packet.

That means the crypto associated to beginning of connection will have to be done twice.

-- 
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/issues/710#issuecomment-320569777

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Aug 2017 06:07:48 +0000 (UTC)

Properly generic handling would throw away the initial TLS context and make a new one when it received Version Negotiation.

Moving the negotiated version is possible, and it seems like a reasonable optimization for cases where two versions both use TLS.

-- 
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/issues/710#issuecomment-320576822

---

From: Mike Bishop <[email-masked]>
Date: Mon, 07 Aug 2017 23:17:04 +0000 (UTC)

Seems fine to me at first glance.

-- 
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/issues/710#issuecomment-320806105