Subject: Re: [quicwg/base-drafts] QUIC Version Ossification (#2496)
From: Christian Huitema <[email-masked]>
To: quicwg/base-drafts <[email-masked]>
Cc: Subscribed <[email-masked]>
Date: Thu, 23 May 2019 05:18:59 -0700
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>

About the QuicVersion TLS extension: I think that EKR had a proposal already. Basically, encode the proposed version number as a TLS option. Optionally, encode the supported options in the client message, ordered by preference, and the selected option in the server response.

The client *could* send the option as a ClientHello extension, but that is not encrypted, so it does nothing t prevent ossification. But if the client sends the ESNI extension, then the TLS extension can be encrypted as part of the ESNI content, and so it is safe.

There is a downside to encoding the version in a TLS extension: it is only readable if the Initial message can be parsed. Parsing requires understanding the format of the Initial message, and that requires understanding the version used for encoding the message. That probably means accepting ossification of the Initial format, which is close to "conceding defeat".

-- 
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/2496#issuecomment-495194683