Re: [quicwg/base-drafts] Short header reserved bits: make available for unilateral experimentation (#2022)

Igor Lubashev <notifications@github.com> Thu, 22 November 2018 06:20 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 151E4128C65 for <quic-issues@ietfa.amsl.com>; Wed, 21 Nov 2018 22:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2LP-OxuvLWk for <quic-issues@ietfa.amsl.com>; Wed, 21 Nov 2018 22:20:28 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DA21277C8 for <quic-issues@ietf.org>; Wed, 21 Nov 2018 22:20:28 -0800 (PST)
Date: Wed, 21 Nov 2018 22:20:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542867626; bh=l+1JASq0RVF3FB2mPUhjKdS46vDC1dXY2lUqyqIE5H4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WLSMBv7WEGUuelynUtw1Sp03t+VI4lAZzSNAp4e3g9SP2Nr77OEieyVVELhacACQz Yxbyf3LMBmYMrZ+z5H+KPpDTh2SdOsNnyIJC3G0BK5SGnqRcwW0OYPIVmQEIyyKrYF OUfqf6aBGje6zlMMYXSt15H/RLHosk57KbH+PDN8=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab517781969b1add723184f485e473c08ec8d0a65992cf00000001180e0caa92a169ce16cbfdb7@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2022/440924853@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2022@github.com>
References: <quicwg/base-drafts/issues/2022@github.com>
Subject: Re: [quicwg/base-drafts] Short header reserved bits: make available for unilateral experimentation (#2022)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bf64aaa6cfa6_2f43fc05f2d45c4733594"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/OnriSkSOWUtpMnQoWc-tS_nIgO4>
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, 22 Nov 2018 06:20:30 -0000

@MikeBishop, if I understand it correctly, you are trying to solve a problem of how to pick two random random bits for greasing, if the sender is not using those bits for anything. I would argue that it is a relatively simple obstacle.

The real obstacle to a sender unilaterally using the two unused bits is _not_ technical.  The problem is WG's desire to prevent implementation of anything observable by the path for the fear that the sender will misuse the bits and accidentally reveal something that the receiver would object to.  I am a bit at awe at this position -- this is beyond the fear of a third-party middlebox vendor; this is a mistrust in the actual party to the connection.  Yet, the majority of the WG seems to strongly support just that position, so we may decide to declare it a consensus position.  In any case, I am glad this got discussed and seems to be getting settled.

-- 
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/2022#issuecomment-440924853