Re: Greasing the QUIC Bit

Martin Thomson <mt@lowentropy.net> Fri, 03 July 2020 00:41 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8C63A0972 for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 17:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lKlrJHKV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L1YLYIyC
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 Q0Yo2CNkKBzE for <quic@ietfa.amsl.com>; Thu, 2 Jul 2020 17:41:28 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509753A096B for <quic@ietf.org>; Thu, 2 Jul 2020 17:41:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 68A5D5C01BE for <quic@ietf.org>; Thu, 2 Jul 2020 20:41:27 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 02 Jul 2020 20:41:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=eOIEkqGlHm1PIFBbXp8wR+0SHdbl2ii CApZRzvLgqlM=; b=lKlrJHKVOG+tkc/Ym1jHc7lkBJd0eKzsnGEZQUbtVNdsLU9 3AsyfBXF6azb0tztqdl/N3Nlamc0iD0FBm3GPEP0HhALBVUYBEJuoAsFfbFAWeNS FRVjZnKR9s7068tQYjrKTP1XbQoWne+fK24EOfcLw8+eWcKQ+OYhqNygoTqdUhxD SzLIR8fI+tZqb7t38SzQTGsuw/CClp0lwGB2yo9D93C8ACQu725qrRyu11uE/fDa EB9oLNppjJWahWepOhHmLzwoClJM++GqivMDm83gbZN0zjwIyqqKaFpWOuXN8rY7 G7rksDqKIoyLKrPrzdLsH04Ni+SxBHAddkHStqg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eOIEkq GlHm1PIFBbXp8wR+0SHdbl2iiCApZRzvLgqlM=; b=L1YLYIyCcSXj1GTCEP+GT9 wCQw8WBzlEwgvrEnJAhk4ZV48FIf2X1/eEFjCbr1AfYkwN603yLPaX2yAHGXHSd6 osqt4GqV+QxzQlGC4seHy+H+1M58HtV8N0jCb4Jh4ruj+PTA8gju+FucuMcyA6+Z bAK2of2pgUgbnk7CP3X8LMpfsGeTyqLc68MAyz8i+hGk3qliMZ913ssxwBXggGaC RTOdTvZFQZfJX6pju52bbx5YR1saynTlk71proV+Tv05gBZRqrnrkRvhk9Oc+aLW 1HtMNuNlZtUArDsbCdujiETdyjUow5EpiRWRzRkSQ1IU7tdGqSdnO8PPpPhHtXsQ ==
X-ME-Sender: <xms:tn7-XqtJjH8H3-Qdkjf4bVDNler80AVIURBuyBPTDBgOSKXVMCXHcw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdehgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:tn7-XvcbhdSvqxXyhI7mp37GEqYV2KIkzVEWckITJpbj0Drlr6xQaQ> <xmx:tn7-Xlwq4QQnoXdbvgDEla7YbGYRt3Mq7Xi9ZZSPyJoLDZnEQU4eHw> <xmx:tn7-XlMdoXk6C2NARO8H1vzt_oFpQ1i8Z_7oqyjGYtRdG9ZhowRu0Q> <xmx:t37-XkdqBYiWWpO0H-8fmRdGfGO7uQEpaRXY2nuDDGH7xnV5kjeYug>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C4940E00D4; Thu, 2 Jul 2020 20:41:26 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <65c908df-7123-46ee-838c-575f8154c811@www.fastmail.com>
In-Reply-To: <CH2PR22MB2086FD91E42AC403D85DC42FDA6D0@CH2PR22MB2086.namprd22.prod.outlook.com>
References: <5943e1bd-fba9-473b-a20f-7992ad0579ab@www.fastmail.com> <CH2PR22MB2086FD91E42AC403D85DC42FDA6D0@CH2PR22MB2086.namprd22.prod.outlook.com>
Date: Fri, 03 Jul 2020 10:41:08 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Greasing the QUIC Bit
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/D-oJZhApqhcp5qH9M-8utL3fnWw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 00:41:30 -0000

Multi-reply, inline...

On Thu, Jul 2, 2020, at 22:57, Stephane Bortzmeyer wrote:
> Isn't it the point of draft-ietf-quic-invariants? If it is not an
> invariant, it may change.

Indeed it is the point of that document, and we do not promise that the value is constant.  But actions are louder than words and QUIC version 1 fixes the bit, so there is the concern that the words in -invariants won't have an effect.


On Thu, Jul 2, 2020, at 23:18, Brian Trammell (IETF) wrote:
> I continue to fear that the demand for on-path discrimination of QUIC 
> traffic will remain [...]

Ack.  The question for me is how much this bit was ever likely to sufficient for that purpose.


On Fri, Jul 3, 2020, at 06:20, Dmitri Tikhonov wrote:
> Why don't you pick a TP number -- let's interop on it during the
> upcoming Interop.

As the rules for the registries allow, the draft has a number in it.  I'll see about implementation.  It shouldn't take too long :)


On Fri, Jul 3, 2020, at 06:38, Mike Bishop wrote:
> Seems like the most straightforward way to grease it to be extending 
> header protection to cover that bit as well.  It's always set to 1, but 
> you change the mask you're using on the first byte of header protection 
> and get instant variability, just like the reserved bits.  I'm 
> surprised the document doesn't mention that way of implementing it, 
> even if it's hardly the only way to achieve an "unpredictable value."

This remains the most difficult question for me.  I spent a good amount of time thinking about this and never really reached a conclusion I was happy with.

The use of the masking to generate an unpredictable value might sound good, but it isn't good.  Unless you can meet some very particular constraints - and you disassemble your AEAD - the value of the mask depends on the value of the bit, so you can't use masking bits to decide the value.  You might save bits from the last packet for the next one, I guess, but that's just an RNG.

It's this that makes the question of masking difficult.

If you mask the bit, then you need to be sure that recipients know when it is masked.  That means you can't apply the new rule for generating the bit prior to negotiating the extension.  In practice, that means you can only realistically affect 1-RTT packets (and maybe 0-RTT packets).

If you don't mask the bit, then you can toggle the value of bit any time you think your peer might be OK with it, including for new connections.  The value you send is what is authenticated.  But that prevents you from masking the value of the bit.  Or at least it makes it much more difficult to use the bit to carry a value for which you require end-to-end confidentiality.  I can think of a couple of tricks, but they require some crypto-juju to avoid some fairly nasty costs.

In the end, not masking is easier to specify and implement, so that was the decider :)  The effect is that this is better suited to path signals than end-to-end signals.