Re: [quicwg/base-drafts] First byte changes (#2006)

Kazuho Oku <notifications@github.com> Mon, 19 November 2018 23:01 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 59E09130DF6 for <quic-issues@ietfa.amsl.com>; Mon, 19 Nov 2018 15:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 XQkvgUd_BYZ6 for <quic-issues@ietfa.amsl.com>; Mon, 19 Nov 2018 15:01:10 -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 44598130DEE for <quic-issues@ietf.org>; Mon, 19 Nov 2018 15:01:10 -0800 (PST)
Date: Mon, 19 Nov 2018 15:01:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542668469; bh=QhwMgpZ4L0goIVcqFM4uUmtZV7o6na/vZl8UtAR8w/E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eh95IyPHwxp23onzUAuImRvWEr1Q4Z5ucbQMGk1gOOHIRkQlaPEmOjXvQQDgUh/7d nrtzv5VOaEWVRJJ7x1Sr1yRcPkbBvW5/mJME9aP9i3YMGRo/odIF3mG/kKefvkjTzd 2G82dfmB9TZoYmfhZ+Uy63HJITaUUjHO2AiT++3s=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab239adadd406a22a2766725acd3c47738168da83392cf00000001180b02b592a169ce16b57ba1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2006/review/176537865@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2006@github.com>
References: <quicwg/base-drafts/pull/2006@github.com>
Subject: Re: [quicwg/base-drafts] First byte changes (#2006)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bf340b51b4d1_16f93f901bed45b426924"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/eibZQ5RDg8wJcRgtV1Nz8x3D2TY>
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, 19 Nov 2018 23:01:12 -0000

kazuho commented on this pull request.



>  
-: The fourth bit (0x10) of byte 0 is set to 1.
+: The next two bits (those with a mask of 0x18) of byte 0 are reserved.  These
+  bits are protected using header protection (see Section 5.4 of
+  {{QUIC-TLS}}).  The value included prior to protection MUST be set to 0.  An

@igorlord 
> The suggestion is that bits can be anything and they are AEAD protected but not masked -- just like the latency spin bit.

Thank you for the clarification. I understand that.

> They could be set randomly or not randomly -- up to the endpoint.

That means that most endpoints will be required to set them randomly, at least initially. The issue here is that you need to randomize the bits separately, rather than just relying on header protection to randomize the bits. It is an complication.

> An endpoint can already disclose any and all info to anyone without peer's consent, and these bits are by far not the most convenient mechanism for such disclosures.

If that is the case, why do we need to care about the bits? If the endpoints have an easier way to expose the information, can't they just be randomized using header protection?

-- 
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/pull/2006#discussion_r234814621