Re: Version Ossification: Intended Scope for QUICv1

Ian Swett <ianswett@google.com> Mon, 11 November 2019 16:57 UTC

Return-Path: <ianswett@google.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 E7EA1120A17 for <quic@ietfa.amsl.com>; Mon, 11 Nov 2019 08:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ZSnDg94AwuXw for <quic@ietfa.amsl.com>; Mon, 11 Nov 2019 08:57:56 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 87565120A0E for <quic@ietf.org>; Mon, 11 Nov 2019 08:57:56 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id b11so12879wmb.5 for <quic@ietf.org>; Mon, 11 Nov 2019 08:57:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m2xHm/M3DEfBdwV5ZdywobemmWeOEtM1fd4OWHtOQUQ=; b=qtjTEqzXHixCI7uQu0EKXIBA/Ds/U6NIkHrCojXFk1oPcYfgk2RUFaycaFtGQGsLFh x4dDVDmVF8xsK5llQLZw3rNBmshOu11mTC/NWfr0DKbN4etFRFRe9rYXMIKLWoVSbqL+ hh/fYnR0klDfHHTSsQZpo/jM+eNi80M4zinCuWroFp/8+taqq9PtmBUoo7gHwc/AVjKT af8ZxhHic43ZDY+MJx1uijB+FQiP5KRLEBI1DNiSBZLPc+KCyvzq3QCeiXOiQhmTFMNS xKET1NEmUARveGr2XdsciT4y+qJkVxUkIeGny7rZtqaNOUAgtGkdVYGVfZpZ3N2H8J/G 37KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m2xHm/M3DEfBdwV5ZdywobemmWeOEtM1fd4OWHtOQUQ=; b=sa/H9NE4NW47wOFuiCmuc4vx5EHdzh8pPAJKqrmVmcYXNQsKknRgyhX9EUWM3kGOp8 0P/WsvQkId6DUHoPEY9TNIRMe6qAOw3mXgdY5+YvynlnyYhYlEzRFOz1qkGdoFgB183j eOe25eeLadBaaZpp/DQtrRRor2IqG2YiFIKQvHhA6r9IUoTyrIjJz4ik61TGfheoM4m/ l4/pSF4dz8mAoR5dnS1qZsYzuH8rkoiqG3PyeN896R5OlGXuiRFBfV1BZhO7wxAX+amm dXo7mR+pD0VGd9+CfyM4AFC9Q4+vc8f9GbdsZEqneqiLseuhChoGXyXXuwa+dQ+RPvaS k1dA==
X-Gm-Message-State: APjAAAWpVrhjmQbfZaKbg3rFTfxliqz4aEJng0em1MyzobfKGUEnug3e FE7AcfndKAmVT3ZY1vxoSgLUNi6yistRi+HNxloTfw==
X-Google-Smtp-Source: APXvYqx8N4DA7ereCCTAip36WxcCDxlVGCiaGzdBwr+U2WtyytGXz0P2F+N2LtzwCS9wBCR5kP3w79sKede/Bpcamfo=
X-Received: by 2002:a1c:4e1a:: with SMTP id g26mr21930067wmh.138.1573491474681; Mon, 11 Nov 2019 08:57:54 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6E79OySoOLbJ8eWp0J-+3yeB5iGvj6sW19bEDn_V7-NA@mail.gmail.com> <CABcZeBN+6p2k+Kj4K5oKNEqKV50aAU6FLGkiZG0dGPNkg1s_-A@mail.gmail.com> <376bcf21-b18f-9199-8054-47122419e1d4@huitema.net>
In-Reply-To: <376bcf21-b18f-9199-8054-47122419e1d4@huitema.net>
From: Ian Swett <ianswett@google.com>
Date: Mon, 11 Nov 2019 11:57:40 -0500
Message-ID: <CAKcm_gM370SxB1UAt3HYfepzQTH4Z+_H8=zAVMdZu322VsONyQ@mail.gmail.com>
Subject: Re: Version Ossification: Intended Scope for QUICv1
To: Christian Huitema <huitema@huitema.net>
Cc: Eric Rescorla <ekr@rtfm.com>, David Schinazi <dschinazi.ietf@gmail.com>, QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068613d059715083d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vwW17zz3gdSVXGL9YKdwEV-QYII>
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: Mon, 11 Nov 2019 16:57:59 -0000

+1 from me as well.

I think this is useful work and I support the QUIC WG working on it, but I
don't believe it needs to be included in v1 and I'd like to get some
deployment experience with it before standardizing it.

On Sun, Nov 10, 2019 at 7:48 PM Christian Huitema <huitema@huitema.net>
wrote:

>
> On 11/10/2019 2:53 PM, Eric Rescorla wrote:
> > I would actually like to suggest something more aggressive (or,
> > conservative, if you prefer), namely that we punt version ossification
> > entirely to the future, whether to an extension or QUIVc2. In support
> > of this proposal, I would make three points:
> >
> > - We are actually going to be running concurrent versions for quite
> >   some time. Even if everyone were to aggressively (say 6-12 months)
> >   deprecate all the draft versions upon shipping the RFC, we're
> >   looking at something that's 18-24 months out. And of course,
> >   I expect people to do some simple version greasing. So, that
> >   probably buys us some time before real bad ossification sets
> >   in.
> >
> > - It's turning out to be surprisingly hard to design a mechanism that
> >   works, as evidenced by David's mechanism. And to that, I would add
> >   that anything that involves having a server hand out some new set of
> >   keys/salts is going to run into the same kind of multi-CDN problems
> >   we had with ESNI (i.e., failures when you get switched between
> >   CDNs). And then recovering from that cleanly either seems to mean
> >   some ESNI-style fallback or allowing a middlebox to forge VN to
> >   force you back to the published version/salt.
> >
> > - It seems like this would all be a lot easier if we had ESNI, because
> >   you could tie the use of the new salt/version to the ESNIConfig
> >   (either as a public or symmetric key, depending on taste).
> >
> > So what I would propose is that we put this problem on ice for now and
> > then revisit it as an extension. All of the proposals that we have
> > seen seem like they could be done as an extension, and then we can (1)
> > get QUICv1 done and (2) hopefully leverage ESNI once we have some
> > experience.
>
> +1
>
> -- Christian Huitema
>
>