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

martinduke <notifications@github.com> Mon, 04 March 2019 22:09 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 []) by ietfa.amsl.com (Postfix) with ESMTP id A8B0D13110E for <quic-issues@ietfa.amsl.com>; Mon, 4 Mar 2019 14:09:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CFPhdWpP1Qog for <quic-issues@ietfa.amsl.com>; Mon, 4 Mar 2019 14:09:31 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744FF1274D0 for <quic-issues@ietf.org>; Mon, 4 Mar 2019 14:09:31 -0800 (PST)
Date: Mon, 04 Mar 2019 14:09:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1551737369; bh=Ac7xYe7Bvyq3Ws+6XK3mHq777fP6nD95t9NhakAdgL8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Y+2rl50uiF+y+/t+g5IbXmcXXjsg181l1hGkxR5cC60kGLGgh9nGCXEJ+B1vXoFZ/ DcHCETHD08OtYLd5oI6lzRW7eby1IP0Y8mS7BcgFt0VODLWE5k+C8/tbWwBf7vNxRK tswmf6sG8sIywX62npuPmmMoVSulYzj59ZOd2xAM=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfb717595e0af8c97c7984ba4e9087ba5bb10e80092cf000000011895641992a169ce18db26a8@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@github.com>
Subject: [quicwg/base-drafts] QUIC Ossification (#2496)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c7da219a501e_54c43f8c9e2d45b46719c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/1SXXKs2mTo0CpKLr6pGogwee6GU>
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: Mon, 04 Mar 2019 22:09:34 -0000

There is a long conversation happening in the mailing list about QUIC version number ossification:
I'm adding it here to bring in others and consider it on the agenda for a WG meeting.

I won't try to summarize everyone's position from the thread. Given the status quo, it would be easy for someone to write a dumb middlebox that drops QUIC version > 1, or indeed version > 2. This appears to have happened with TLS v1.2. Given all of our effort to counter ossification, it would be tragic if we fell down on this rather simple hurdle.

There is disagreement as whether obfuscation is valuable or not. Though I have no answers, I personally would like to explore a few questions:
1) Are there any changes to VN we can make to reduce the chance of ossification happening?
2) If ossification happens anyway, do we have strategy to do something to overcome it?
3) If we are going to end up with some more obscure mechanism, does it make sense to lock in on bytes 2-5 of every long header to be 0x00000001 in perpetuity?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: