Re: Greasing the QUIC Bit

Christian Huitema <huitema@huitema.net> Sat, 04 July 2020 02:03 UTC

Return-Path: <huitema@huitema.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 B54783A09F1 for <quic@ietfa.amsl.com>; Fri, 3 Jul 2020 19:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pZmB_ToAa1Up for <quic@ietfa.amsl.com>; Fri, 3 Jul 2020 19:03:57 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BBE3A09EC for <quic@ietf.org>; Fri, 3 Jul 2020 19:03:56 -0700 (PDT)
Received: from xse44.mail2web.com ([66.113.196.44] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jrXWy-0000bd-HW for quic@ietf.org; Sat, 04 Jul 2020 04:03:56 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49zFTr18rbzsy6 for <quic@ietf.org>; Fri, 3 Jul 2020 19:02:56 -0700 (PDT)
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jrXW4-0008Rv-19 for quic@ietf.org; Fri, 03 Jul 2020 19:02:56 -0700
Received: (qmail 11240 invoked from network); 4 Jul 2020 02:02:55 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.187]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 4 Jul 2020 02:02:55 -0000
To: Martin Thomson <mt@lowentropy.net>, quic@ietf.org
References: <5943e1bd-fba9-473b-a20f-7992ad0579ab@www.fastmail.com> <CH2PR22MB2086FD91E42AC403D85DC42FDA6D0@CH2PR22MB2086.namprd22.prod.outlook.com> <65c908df-7123-46ee-838c-575f8154c811@www.fastmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Subject: Re: Greasing the QUIC Bit
Message-ID: <9db597a6-5e75-4df6-5447-8204d052100c@huitema.net>
Date: Fri, 3 Jul 2020 19:02:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <65c908df-7123-46ee-838c-575f8154c811@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.44
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.44/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.44/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fvM/3F/AXWdXzEQzS8FaCI6U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/G0KF6HkLuWi8fS7fvK7Hsbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilU9uaDsIPkO9 NcV2UWdi7rYNgfslPwgLMPeV3suSDRJVQ7lpL9conbe783Tp56fR5xPXEv3EDaPA1IUvTVmP7JuH gbVpRK3T9+h2PwMALJBC8U0Qc2cItWeQn0hrqUcNc7dCp3Zd9clP8wSiJZWbJCg35R5vCGCRun6Y x0PkyFKGUmJL8/wiW6IDBeXl/RY0UzXg724gFzhHYUe+7aKm0vWiWEaYW9QKOiKrsHvklItbTi+J 2sBvM/O0p+zizleC4lU8fDj1CnRx+r4b/1Q/PZ/Um5+9cYZbxLoI+xclcaT5vOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RLU3nfnEGx0tayfLe5LttjsZbFI>
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: Sat, 04 Jul 2020 02:03:59 -0000

I am almost done implementing this in picoquic, I just have a question
about to set the quic bit if the option is negotiated

The spec says "use an unpredictable value", and I am hesitating between
three options:

1) flip a coin upon negotiation of the TP, and set all Quic Bits for the
connection to the selected value.

2) flip the bit at every packet.

3) run a random number generator for each packet.

The problem is that it has to be both unpredictable and testable.
Testable would mean "run a test connection, and check that the Quic bit
is zero some of the time". This kind of rules out the "one coin per
connection" option, because then some connections will never set the bit
to zero. Flip on every packet is testable, but is hardly unpredictable.
The RNG is a statistical test. It can still statistically fail, unless I
run the test for long connections. Also, it is hard to make it
repetitive. I will probably end up with some RNG variant, but this does
not make me too happy...

-- Christian Huitema

On 7/2/2020 5:41 PM, Martin Thomson wrote:
> 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.
>