Re: [quicwg/base-drafts] QUIC Version Ossification (#2496)

Christian Huitema <notifications@github.com> Thu, 23 May 2019 12:19 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A21200B3 for <quic-issues@ietfa.amsl.com>; Thu, 23 May 2019 05:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PEVMDZR2l-O for <quic-issues@ietfa.amsl.com>; Thu, 23 May 2019 05:19:00 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FE812008A for <quic-issues@ietf.org>; Thu, 23 May 2019 05:19:00 -0700 (PDT)
Date: Thu, 23 May 2019 05:18:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558613939; bh=fsUeMOyUs5iYfv2Mc8TeHdLDJLVq6HcT3GmPzmOpY+Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=E7hRWDOSgu10CN0TRZhAw9VGiLjTHLBs6cQRKwnFjYJviMRBYhLl3qowX5tVPlXud MiUCOFyVztvyPVNqHhJdT7gBK0l8vvSpxcapTlnu7dwVldU7ZaDtdmPZ3eWLI8dB0i RfXwirYhIvFX41QWv1GFc8Dy03wugZjEIgUw+yXM=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3YBJH3TQK5MDSC3XN26PBDHEVBNHHBRWZGVA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2496/495194683@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2496@github.com>
References: <quicwg/base-drafts/issues/2496@github.com>
Subject: Re: [quicwg/base-drafts] QUIC Version Ossification (#2496)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce68fb37b70a_33a53fb3aaccd95c9073f8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/kqkNMPY10xuY_2k8g3WJpZxQ9tQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 12:19:02 -0000

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