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

Marten Seemann <notifications@github.com> Thu, 15 November 2018 04:52 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 15A831271FF for <quic-issues@ietfa.amsl.com>; Wed, 14 Nov 2018 20:52:37 -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 5mMsnStrVI92 for <quic-issues@ietfa.amsl.com>; Wed, 14 Nov 2018 20:52:34 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1110D130E06 for <quic-issues@ietf.org>; Wed, 14 Nov 2018 20:52:33 -0800 (PST)
Date: Wed, 14 Nov 2018 20:52:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542257552; bh=gV6Qjg+UdcfaTiBVWDnzrl3SDVP6mOasHTmQ5fm7vw4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=n6RgIR1kGzWHSDihuWfJAJGyWw2UMUWHCsrDCMVzZd1nOQF7l1x0rcgeWvEA3GFMl 5SXqM9A7CLnBxrXOnTyc9r34eZYxNSJop4dpNgziJzxYyuTnW9Hv9F5vsUc7BTZnoR I2DV3+VXxgCXkzQkInDHiiuXuvJA+sCc7J03hnhk=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe1400a2796a1bf47c9adf0fd965b86450af013c492cf000000011804bd9092a169ce16b57ba1@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/175187692@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 octet changes (#2006)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5becfb90aef15_7cb33fc9c24d45c462164c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/waKaUoIE-LNQ-hXijPxyUnZiKkg>
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, 15 Nov 2018 04:52:37 -0000

marten-seemann commented on this pull request.



> @@ -3271,15 +3257,35 @@ Header Form:
 : The most significant bit (0x80) of byte 0 (the first byte) is set to 1 for
   long headers.
 
-Long Packet Type:
+Fixed Bit:
+
+: The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value
+  for this bit are not valid packets in this version.

Should we say that those packets are supposed to be dropped?

> @@ -3353,8 +3354,8 @@ following sections.
 The end of the packet is determined by the Length field.  The Length field
 covers both the Packet Number and Payload fields, both of which are
 confidentiality protected and initially of unknown length.  The size of the
-Payload field is learned once the packet number protection is removed.  The
-Length field enables packet coalescing ({{packet-coalesce}}).
+Payload field is learned once the header protection is removed.  The Length

Why is that? The Payload Length is not encrypted, is it?

>  
-Third Bit:
+: The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value
+  for this bit are not valid packets in this version.

Same here.

> +with the remaining bytes.
+
+{{pseudo-hp}} shows a sample algorithm for applying header protection. Removing
+protection only differs in the order in which the packet number length
+(pn_length) is determined.
+
+~~~
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] & 0x03) + 1
+if packet[0] & 0x80 == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] & 0x0f
+else:
+   # Short header: 5 bits masked
+   packet[0] ^= mask[0] & 0x1f

This doesn't say anything about peers that are not spinning, in which case it should be 6 bits.

>  
-\[\[Editor's Note: this section should be removed and the bit definitions
-changed before this draft goes to the IESG.]]
+: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
+  {{!SPIN=I-D.ietf-quic-spin-exp}}.

Do we need to say something about peers that are not spinning?

> @@ -3677,7 +3666,7 @@ wishes to perform a stateless retry (see {{validate-handshake}}).
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+
-|1|    0x7e     |
+|1|1| 3 |ODCIL(4|

It's kind of weird to have the ODCIL length field so far before the ODCIL. On the other hand, it saves a byte, and fills unused bits.

>  
-: 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
+  endpoint MUST treat receipt of a packet that has a non-zero value for these
+  bits after removing protection as a connection error of type
+  PROTOCOL_VIOLATION.

This only applies to packets that are successfully encrypted. Should we mention that?

-- 
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#pullrequestreview-175187692