Re: [quicwg/base-drafts] First octet changes (#2006)
janaiyengar <notifications@github.com> Thu, 15 November 2018 11:35 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 D1AB8128BCC for <quic-issues@ietfa.amsl.com>; Thu, 15 Nov 2018 03:35:24 -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 pFAGwp1PXbtQ for <quic-issues@ietfa.amsl.com>; Thu, 15 Nov 2018 03:35:22 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C8612872C for <quic-issues@ietf.org>; Thu, 15 Nov 2018 03:35:21 -0800 (PST)
Date: Thu, 15 Nov 2018 03:35:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542281720; bh=ZhTJJmysaAtcmQ0TiaFF/Hm+okyx42PwvC6R/P0l/DA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=v8WmO1gqahq7JY6vjx6iqHBS0nbf6NWaSkWF7U4CijGq2WleAXBZw2gA79lhXTB9R DEu/vvIokwEUSs2X6aECoMi5KWPhOToB+sjs2Rs5NIqPPdSFYThWuXWiujRFbe0YJl UDGRuqcUCMFDW6jtlCWLeqMVryzQP+BTKl2O2oog=
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6a328bcf8d5032e126cdca77e16038b8ddeb651392cf0000000118051bf892a169ce16b57ba1@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/175293530@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_5bed59f8af2e1_72b23fd4a8ad45b439448d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/ZGFZVvbZrQ2La1moFTKBSmnzHf8>
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 11:35:25 -0000
janaiyengar commented on this pull request. > @@ -771,10 +771,9 @@ used for QUIC packet protection is the AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. -QUIC packets are protected prior to applying packet number protection -({{pn-encrypt}}). The unprotected packet number is part of the associated data -(A). When removing packet protection, an endpoint first removes the protection -from the packet number. +Packets are protected prior to applying header protection ({{header-protect}}). +1. I think this clarity will help. > -To ensure that this process does not sample the packet number, packet number -protection algorithms MUST NOT sample more ciphertext than the minimum expansion -of the corresponding AEAD. - -Packet number protection is applied to the packet number encoded as described in -Section 17.1 of {{QUIC-TRANSPORT}}. Since the length of the packet number is -stored in the first byte of the encoded packet number, it may be necessary to -progressively decrypt the packet number. - -Before a TLS ciphersuite can be used with QUIC, a packet protection algorithm -MUST be specifed for the AEAD used with that ciphersuite. This document defines -algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, -AEAD_AES_256_CCM (all AES AEADs are defined in {{!AEAD=RFC5116}}), and -AEAD_CHACHA20_POLY1305 ({{!CHACHA=RFC8439}}). +To ensure that this process does not sample the packet number, header protection +algorithms MUST NOT require sample that is longer than the minimum expansion of ```suggestion algorithms MUST NOT require a sample size larger than the minimum expansion of ``` > @@ -3050,6 +3050,7 @@ IP addresses has fallen below 1280 bytes, it MUST immediately cease sending QUIC packets on the affected path. This could result in termination of the connection if an alternative path cannot be found. + ```suggestion ``` > -number of bits required to represent the packet number is first reduced by -including only a variable number of the least significant bits of the packet -number. One or two of the most significant bits of the first byte are then used -to represent how many bits of the packet number are provided, as shown in -{{pn-encodings}}. - -| First byte pattern | Encoded Length | Bits Present | -|:-------------------|:---------------|:-------------| -| 0b0xxxxxxx | 1 byte | 7 | -| 0b10xxxxxx | 2 | 14 | -| 0b11xxxxxx | 4 | 30 | -{: #pn-encodings title="Packet Number Encodings for Packet Headers"} - -Note that these encodings are similar to those in {{integer-encoding}}, but -use different values. +Packet numbers in long and short packet headers are encoded on 1 to 4 octets. ```suggestion Packet numbers in long and short packet headers are encoded in 1 to 4 octets. ``` > -including only a variable number of the least significant bits of the packet -number. One or two of the most significant bits of the first byte are then used -to represent how many bits of the packet number are provided, as shown in -{{pn-encodings}}. - -| First byte pattern | Encoded Length | Bits Present | -|:-------------------|:---------------|:-------------| -| 0b0xxxxxxx | 1 byte | 7 | -| 0b10xxxxxx | 2 | 14 | -| 0b11xxxxxx | 4 | 30 | -{: #pn-encodings title="Packet Number Encodings for Packet Headers"} - -Note that these encodings are similar to those in {{integer-encoding}}, but -use different values. +Packet numbers in long and short packet headers are encoded on 1 to 4 octets. +The number of bits required to represent the packet number reduced by including ```suggestion The number of bits required to represent the packet number is reduced by including ``` > @@ -3210,27 +3196,27 @@ arrives after many higher-numbered packets have been received. An endpoint SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards. -As a result, the size of the packet number encoding is at least one more than -the base 2 logarithm of the number of contiguous unacknowledged packet numbers, -including the new packet. +As a result, the size of the packet number encoding is at least one bit more +than the base 2 logarithm of the number of contiguous unacknowledged packet ```suggestion than the base-2 logarithm of the number of contiguous unacknowledged packet ``` > @@ -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. For consistency, I would say that receipt of zero here should be treated as a connection error of type PROTOCOL_VIOLATION. > -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 error here. > -\[\[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}}. I think we should leave that to the other doc. > -: 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. @marten-seemann : did you mean "after successfully removing header protection"? I don't think you need to wait to remove packet / payload protection before doing this. -- 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-175293530
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- [quicwg/base-drafts] First octet changes (#2006) Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… janaiyengar
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… ianswett
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… erickinnear
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Dmitri Tikhonov
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… David Schinazi
- Re: [quicwg/base-drafts] First octet changes (#20… Christian Huitema
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… Dirkjan Ochtman
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Marten Seemann
- Re: [quicwg/base-drafts] First octet changes (#20… Christian Huitema
- Re: [quicwg/base-drafts] First octet changes (#20… Kazuho Oku
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First octet changes (#20… MikkelFJ
- Re: [quicwg/base-drafts] First octet changes (#20… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… ianswett
- Re: [quicwg/base-drafts] First byte changes (#200… Christian Huitema
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Mike Bishop
- Re: [quicwg/base-drafts] First byte changes (#200… MikkelFJ
- Re: [quicwg/base-drafts] First byte changes (#200… David Schinazi
- Re: [quicwg/base-drafts] First byte changes (#200… David Schinazi
- Re: [quicwg/base-drafts] First byte changes (#200… Dmitri Tikhonov
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Marten Seemann
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Alexandre Ferrieux
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… janaiyengar
- Re: [quicwg/base-drafts] First byte changes (#200… Kazuho Oku
- Re: [quicwg/base-drafts] First byte changes (#200… MikkelFJ
- Re: [quicwg/base-drafts] First byte changes (#200… janaiyengar
- Re: [quicwg/base-drafts] First byte changes (#200… Igor Lubashev
- Re: [quicwg/base-drafts] First byte changes (#200… Christian Huitema
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson
- Re: [quicwg/base-drafts] First byte changes (#200… Martin Thomson