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
- QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Ian Swett
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification David Benjamin
- RE: QUIC ossification Mike Bishop
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Ian Swett
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Erik Kline
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Kazuho Oku
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Mirja Kühlewind
- RE: QUIC ossification Mike Bishop
- Re: QUIC ossification Martin Duke