Re: QUIC ossification

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sat, 23 February 2019 07:03 UTC

Return-Path: <mikkelfj@gmail.com>
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 EF6D7131025 for <quic@ietfa.amsl.com>; Fri, 22 Feb 2019 23:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=gmail.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 c283C_UH5CP7 for <quic@ietfa.amsl.com>; Fri, 22 Feb 2019 23:03:00 -0800 (PST)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5500A12F295 for <quic@ietf.org>; Fri, 22 Feb 2019 23:03:00 -0800 (PST)
Received: by mail-it1-x12f.google.com with SMTP id z124so6603682itc.2 for <quic@ietf.org>; Fri, 22 Feb 2019 23:03:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wqYQ4BFcuDcgVMhVL3EMmvkt4L2v9SMQOqtJfWFjHZg=; b=nVTJqjP02Dw4wPdr/iuw5RJChLQy96wRXQpBoJR2bvJuOPyf37r2pNDNg6qH2WbQnu 0OisVxkEa8gMspmMjZIYHXIwkjz0HiV9pbEPInAZlfvvDAQHwOjxzJVDyQZKx9z9KyBc f57NQ2n+aS7Nzkibnr0yjedSaHVvb1UAv/t0TjA09wP3WxPXmNQPA+vphLvwid81XRyd Og09N6YN86eH+vOglQ/t3xR61uyp6qynbkrysGVMcoznmwtskKl1v1LXNudXwEFe8xl8 i0pVkZCVXbFj/fLomcyTMds4ht2hCmP2EVk2gCWATje9RBtpzC+dwczB6XFIfu9IMvFw Q4hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wqYQ4BFcuDcgVMhVL3EMmvkt4L2v9SMQOqtJfWFjHZg=; b=iOPJdukbkfeCTl/lpOiue5jcizUbskTh2JS8JvCDs1YdjKZtchC4jyoGAX6dNoEi0N 0SlOkjrsZxOP6XWpsh6TPNlzaNLVMftHmWzksUJSq384B5viurTWDbqtuGdmMycw6NRY bSxLZaHQFEAAZHAM6YwJQz75ruFQFxlIKvg5dV8el5EeVH/tS2RclS4HReuQ/8HCtztb 3x91wAGByVxBFM6lZPV6G6+3fctT/vNQTB9Cm6Z+m16kTuoS6ZMn6u8T1VqZivrYOpLZ J0EAWPPmIwzYtF0vx5/pWZ8d1MaY35Oa8RXHRMdd+qrcnN+3uJVQh3e8TjvN4XdH46wu LdcA==
X-Gm-Message-State: AHQUAubl8I9eC7nxzplQpUqVL4CYby+vYLvFBmKnjxZndFzgjUOiDtwZ AA93H//9ugsJQI0/h9X+dhDzPrvgzjHx0z2GxEA=
X-Google-Smtp-Source: AHgI3IYu6Pq43xxhJQOp302FbXZifXTR+4EE2zXV/+GTjVuHJsrZ4birSfu3fi8R7/MZQoN3XV7dKdGO96K95eV4tzk=
X-Received: by 2002:a24:4487:: with SMTP id o129mr4114150ita.167.1550905379250; Fri, 22 Feb 2019 23:02:59 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Feb 2019 23:02:58 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <d9b2ed51-a231-26e7-7ee8-08527b5fbfb1@huitema.net>
References: <f76aa399-f35d-46c5-b6a7-043d8704a90e@www.fastmail.com> <CACpbDcf_temqJ3EesvboKt280m-TEucMqa-NpYW7-UC5r0p1mQ@mail.gmail.com> <783327C4-3877-48F4-A41A-5987458C39B7@fb.com> <CACpbDccFRWeSYFGu7cjdsrWAnE_6KbhpPMZJ9kzN1KviAfEGJQ@mail.gmail.com> <067D562F-AC7C-463D-9C4D-D5ECF4D50FC9@trammell.ch> <C9BC63FD-9BE2-47B8-8D1C-EC27CEDF4D42@trammell.ch> <CACpbDcf+eE_bO4ZN3vjBmrrJ2oB4-yCZ2WVEX6vkxjKJOmk6ww@mail.gmail.com> <CAAedzxqD8UL39vaxRrugLZR38hXPK9gB8PqPi=kmG2D=eUpcmg@mail.gmail.com> <DAC9E580-909C-4E9E-82E0-A6AB22CADA24@fb.com> <50fa8e3a-a997-4c09-ba38-b8cdcde3b27c@www.fastmail.com> <d9b2ed51-a231-26e7-7ee8-08527b5fbfb1@huitema.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 22 Feb 2019 23:02:58 -0800
Message-ID: <CAN1APdcY7zJOcKmNwvukz0a705WWxO31yJME6GD3LEnDZj_6WQ@mail.gmail.com>
Subject: Re: QUIC ossification
To: Martin Thomson <mt@lowentropy.net>, Christian Huitema <huitema@huitema.net>, Roberto Peon <fenix@fb.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035eb7f05828a4cd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/J-j_w41LX6Oa0D6c92PLD_suMAo>
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, 23 Feb 2019 07:03:03 -0000

But if it is standard enough, then the villains that design the
middle-boxes will know everything about it, and won't stop stroking
their furry white cats for even a second

hear

I fear we are making the already complicated concept of vneg more difficult
without any actual benefit.

But if we must obfuscate, I’d prefer a longer version id of 128 bits and
use secure hash or crypto.

And if not, can’t we please make use of Fibonacci numbers somehow - Roberto
already suggested adding two numbers.



On 23 February 2019 at 04.03.35, Christian Huitema (huitema@huitema.net)
wrote:

On 2/22/2019 3:06 PM, Martin Thomson wrote:

> Leaving the specifics of the proposal aside for the moment, the problem
here is that we have no shared context AND we want to ensure that
legitimate endpoints don't have to go to extreme measures to get the
information they need. A little obfuscation might get us somewhere (esp. if
we are willing to burn either more octets or part of our existing space),
but let's try to focus on what we think we're going to achieve by doing
something here.
>
> Funny that TLS are concurrently talking about hiding the existence of
ESNI, which has so many of the same constraints: you have to standardize
the semantics so that it can be decoded, but you would rather that only the
intended recipient was able to read it. In both cases, the answer is that
you lose because you have no shared keys that would enable the only thing
that we know works (crypto). (I haven't ingested Stephen's long email
there, maybe he has a brilliant idea for breaking the deadlock, but I doubt
that it will help us here, because at least with ESNI you *maybe* have a
key and it seems to be using crypto.)


Martin, you seem uncharacteristically restrained today. How about, "If
it is not encrypted, middle boxes will ossify, and pathetic efforts at
obfuscation are not going to save you?"

I get the point about grease, etc. But grease mostly works between
semi-consenting endpoints, such as QUIC peers who might have forgotten
to actually implement a part of the extension mechanisms. Greasing
Transport Parameter codes, for example. In the case of version numbers,
we have a quandary. We can only use a scheme that is standard enough
that many implementations understand what a particular version means.
But if it is standard enough, then the villains that design the
middle-boxes will know everything about it, and won't stop stroking
their furry white cats for even a second.

-- Christian Huitema