Re: The first octet

Martin Thomson <> Wed, 08 August 2018 07:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB246130DC6 for <>; Wed, 8 Aug 2018 00:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vK7rR6dsP5co for <>; Wed, 8 Aug 2018 00:17:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F009130DC0 for <>; Wed, 8 Aug 2018 00:17:15 -0700 (PDT)
Received: by with SMTP id d189-v6so2065636oib.6 for <>; Wed, 08 Aug 2018 00:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lB/EZ9sS2dwgMbWOtbr3fSlt5WDcKLuIjwaWhnjr5Nc=; b=Zn8o/mXAGFnKivHp2e7KdkbJea8rWFpUIy6HCf0ZtpiAGspIYudcDobSfWWUE2RJla jOSPtnZlp5DC8LtRkCoww6iB9CH8VfYshz7/jCg4t4YbO0v+u7Vfh0nKIXyANiaBXSG1 ZE9t/1//MSkVy5gF2QjojFyt3SWqFQoCRdX5HuPwpEBnlG8UNssJPElZZy9pWzUCWktD bBeKD0PalQDBhdzcdciolS7b4OjRfFv7VWcD1n/ljPegmUxVGLPEn0ILgLDu1nYNCSUJ cLWAvvF0wqUb10ecEWPmF0nVtAULDvPMXVO/UpQhdQrdEcXRF07++mbaGIKhO9ZrETfb /X6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lB/EZ9sS2dwgMbWOtbr3fSlt5WDcKLuIjwaWhnjr5Nc=; b=NNjrlG8VUsVFDWUGSk7rHcRoYGu8hgusDbwoWdCCeDZMLoQp1CEV6tjbceaLxCjvDF ZSetrsJqpbj/RnX6t+EGwm27GmrCDkQPQI2YsMySJ3hzMFLhJNURZ+fLBN2OYpaUJonm 3RpWHcmzqd/8vTg+hK+N8xK82x9PEuE0FGQ3IO/AcMardS/qHgmuFTjQbbWYRGn9QeJd DQSlvnFX/4Ow13Yp73vY2ZhRAX9IsrNDlpwblLlTzOlIjHNfkDUKcY8a7LOQDpeiHU4a dK5cehecPECRM6e2Y0GchhjFvr9ufEXgyusn/oWgTMkhCF1oVZ5xrlgHU2EPoXYlXdnf c/ow==
X-Gm-Message-State: AOUpUlErIJIDSoysHuP6B97BgEq8LvF1Rn6Zfksumn6M07TkX1/s8Al+ 0XPLaadajDq+y2kRcxgLxVvglsefhNmIwwD/sK32cTBYYzI=
X-Google-Smtp-Source: AA+uWPz8STFpv38XK9bG8B2JXHLLesoxWEKve1LitwPT5ElGAsU8QeMdGuT8sPDQqrfDAscomOO3g8FoahxmrJp7wgU=
X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr1868561oiq.110.1533712634649; Wed, 08 Aug 2018 00:17:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 08 Aug 2018 17:17:02 +1000
Message-ID: <>
Subject: Re: The first octet
To: Kazuho Oku <>
Cc: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Aug 2018 07:17:20 -0000

Thanks for sharing your perspective Kazuho, I have a slightly
different view, but it's fairly consistent with yours.  Reformulating
the second question is good, and I too would like to encrypt this
stuff.  It should be easy enough to do so.

I too like the common form for packet number lengths.  I can even see
adding key phase to long header packets for the purposes of

This is my preferred layout for the case we have three bits for spin.

1 t t t t p p p
0 1 s s s p p p

Where p p p is an encrypted key phase bit and two-bit packet number
length (1,2,3,4).  I think that we can afford to have fix tttt values
with no greasing.  Allocating four bits and using two of them isn't so
bad.  By doing that we can choose types that don't conflict with RTP.
It's not necessary, but it's very cheap.  The fixed bit keeps the
short header away from most of the RFC 7983 protocols without costing
much (you had a reserved bit anyway).

The extra fixed bit here makes QUIC short header packets conflict only
with TURN channels from 7983.  That's totally acceptable and fairly
cheap from our perspective.  If you are concerned about ossification
of this bit, we could give it to the spin bit(s) and force the people
who want this sort of demux to negotiate the spin bit into a fixed
value if they care to have good demux.

If we have two fewer bits of spin, that's where things get
interesting.  I would prefer to keep the same ppp bits, but leave the
two spare bits unallocated, but encrypted along with ppp.  Encrypting
means they can be forced to be zero unless agreed otherwise (MBZ
normally means MUST send zero, MUST ignore non-zero, but I prefer MUST
reject non-zero here):

1 t t z z p p p
0 1 s z z p p p

The hit here is RTP.  We would need all type values so we end up using
0b10xxxxxx.  We can limit the damage by changing codepoints for 0-RTT
and Retry packets, which can be avoided in most scenarios that use RTP
(signaling FTW).

If we have no spin bits, then we might as well change the single s bit
to a fixed 1.  Then we avoid TURN channels as well.

On Tue, Aug 7, 2018 at 3:39 PM Kazuho Oku <> wrote:
> 2018-08-06 14:55 GMT+09:00 Martin Thomson <>:
> > It appears as though we're about to get some information about how
> > deployable the QUIC invariants are.  Ian tells me that Google are most
> > of the way to deploying a protocol that uses QUIC invariants and
> > should be able to confirm that this works by the interim.  Well,
> > either that or to be able to tell us what doesn't work, which I'm
> > hoping isn't a problem we have to deal with.
> >
> > I'd like to spend some time at the interim on what we do with the type
> > bits in the protocol.  This email is an attempt to thoroughly cover
> > the constraints that we have here and attempt to describe a process
> > that I hope should get us to a conclusion shortly after Bangkok.
> >
> > Looking at open design issues, this cluster is the one that is the
> > biggest threat to our schedule.
> >
> > Design Status and Constraints
> >
> > Long Header
> >
> > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we
> > have are currently allocated to the 4 types of long header packet,
> > using only 252-255.  All other values are currently unused.
> >
> > With respect to design constraints, there is only one that I'm aware
> > of and that is a potential collision with RTP (and RTCP) on this octet
> > (see RFC 7983), which use 0x10xxxxxx (128-191).
> >
> > The open question here is what we do with unused types.  We might
> > debate creating a registry for unused values.  We might want to grease
> > values.  We could even decide to encrypt these values (though the
> > design of Retry makes that more difficult, because the contents of
> > that packet aren't encrypted at all).
> >
> > I'm not aware of any plans to use these bits, except perhaps what
> > might be done to be consistent with the short header changes, so we
> > might have some latitude here.
> >
> > Short Header
> >
> > The short header uses the 0b0xxxxxxx pattern (0-127).  This is far
> > more complex and we have a bunch of open questions that will make this
> > difficult.
> >
> > Right now, we use the 0b0K110RRR as the pattern, with K being the key
> > phase, and RRR being reserved for the spin bit experiment.
> >
> > Those fixed bits are (largely) temporary, and might be reclaimed once
> > existing deployments of Google QUIC (pre-44) are phased out, so I
> > think that we might want to reclaim some or all of them.
> >
> > There is a chance that the reserved bits will also become available
> > (if not all, then maybe 2 of them).  That will be decided in Bangkok,
> > but we might want to have a plan for those bits.
> >
> > The constraints that I am then aware of are these:
> >
> > 1. RFC 7983 has the lower half of the first octet fairly densely
> > populated for demux.  Of the protocols there, my understanding of
> > their relative importance puts STUN (0-4) as fairly critical, if not
> > mandatory, then TLS (20-63) as optional.  ZRTP (16-19) and TURN
> > channels (64-79) are both apparently unimportant, though each might be
> > opportunistically accommodated.
> >
> > 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits.  I
> > suggest that we allow for this, not counting on having any more bits
> > than N-3, or assuming that only that many bits will be available.
> >
> > 3. Kazuho points out that the key phase is a linkability vector.  We
> > might want to consider encrypting that.  We could do that by fixing
> > the packet number key and not updating it after key updates and using
> > more output from that process to mask the bit (and maybe other bits in
> > this field).
> >
> > 4. I realize that we don't have to put a key phase in every packet if
> > we are less concerned about being able to update immediately.  If we
> > adopt a scheme to what was proposed in DTLS, then a longer encoding
> > can be used during the preparation and signaling phase.    I'll follow
> > up with another email on this subject.
> >
> > One thing that we could use extra bits for is to move the packet
> > number size back into this octet.  We could even move packet number
> > bits back, depending on available space.  That might make some
> > difference to the number of bytes we allocate for packet numbers.
> >
> > Process
> >
> > Given that we don't have answers to some questions we might conclude
> > several ways.  I proposed that we agree on principles, starting with:
> >
> > 0. (This should already be agreed, but I'm repeating it because it's
> > important.)  The low 7 bits of the first octet are version-specific
> > and can change in the next version of the protocol.
> >
> > A. What do we want to do with unused bits?  Do we want to ensure that
> > they are always used?  Or can they be reserved?  If so, how would they
> > be reserved (fixed values, random values, greasing, etc...)?
> As Jana has suggested, I think that the bits must look like random to
> observers, based on our agreement that the bits are version-dependent.
> Unless we make them look like random, there is fair chance that they
> will be ossified.
> >
> > B. Should things in the first octet be encrypted where possible (for
> > example, using an extension of packet number encoding).
> I would rather rephrase the question to "do we need to encrypt foo?" I
> think that we should decide what will go into the first octet based on
> the agreement of what needs to be encrypted.
> Having that said, I think that we need to encrypt packet number,
> packet number length, and the key-phase bit. The packet type bits and
> the spin bit(s) need to be in cleartext. Unused bits can be
> seemingly-randomized as an output of encryption, or could be a random
> value.
> My preference regarding the design will be to have the packet number
> length bits and the key-phase bit in the first-octet next to each
> other, encrypting the two using the PNE key.
> Having packet number length at a different location than the packet
> number itself will simplify the implementation, gives us more chance
> to use shorter encodings for packet numbers.
> For example, the long and short packet header will look like below (e
> - encrypted values of PN length and key-phase, t - long header type
> bits, s - spin bit, R - reserved bit).
> long: 1 e e e R R t t
> short: 0 e e e R s s s
> I do not have a preferred way of randomizing the R bits. They could be
> randomized by PNE along with the e bits, or we could require them to
> be randomized separately.
> >
> > C. Should packet number encodings should be consistent between long
> > and short header forms?
> Yes.
> I do not think that we need to be clever in saving one bit or two. We
> already waste certain number of bits. The fact that we are using
> varint encoding that changes the length at octet-level (i.e., 8 bits,
> 16 bits, 32 bits, ...) means that we are wasting something like 4 bits
> by average per varint. We are also wasting 2 bits per frame,
> considering the fact that the upper 2 bits of a frame is not used.
> > D. What should we do with key phase?  This was an open issue from the
> > stream 0 design team, which might alter the outcome here.  I have
> > another email that covers this in more detail.
> I think we should the bit in every packet as an encrypted value. The
> reason why having I consider that the bit in every packet is stated
> above.
> > E. How should we accommodate multiplexing?  For me, the big questions
> > here are whether we allow for RTP to collide with the long header and
> > which of the protocols we privilege by avoiding with the short header.
> I would prefer not caring about multiplexing.
> We do not guarantee multiplexing between QUICvX and other protocols.
> Considering that, I am inclined to not discussing about
> multiplexability of  QUICv2 (formerly v1), because that would raise
> the chance of QUIC becoming ossified.
> > My hope is that reaching conclusion on those principles should allow
> > us to to agree on designs that allow for 0, 1, or 3 bits of spin bit.
> > That way we know what to do with the outcome of the discussions we
> > plan to have in Bangkok and can implement the changes relatively
> > quickly.
> >
> > For those who read this far, if you have opinions on what principles
> > should drive this design, please respond here.  If you have a proposed
> > design (or designs) and can explain the principles that are expressed,
> > that's OK too.  If this gets enough feedback, I might arrange a call
> > for interested parties.
> >
> > I don't expect that we'll reach a conclusion before the interim, but I
> > don't think that we can let this go unresolved much beyond that point.
> >
> --
> Kazuho Oku