Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 08 January 2021 19:15 UTC

Return-Path: <spencerdawkins.ietf@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 232263A11F9; Fri, 8 Jan 2021 11:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 tiaf626BFMD3; Fri, 8 Jan 2021 11:15:14 -0800 (PST)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 D1B043A11FC; Fri, 8 Jan 2021 11:15:13 -0800 (PST)
Received: by mail-yb1-xb2b.google.com with SMTP id u203so10353027ybb.2; Fri, 08 Jan 2021 11:15:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6eqMMcGn0CN50Ybvtz7MOv3ze2oYFbKpQaHbePRoBgA=; b=HPt4fgIvqdfnZyFJsEXuLrjmJeauwBQcx85dQXaYbV2f9MWCUlczeKQbCqjbWOQaPJ pgO9xGS7LRMfi1M14WoeZfzWK/PBoweakZD0PNHjdPzSQxu7J3VVKsPxN0rNiOeOSYNq KWNaQeUphdWMMc+TEPvRdeQTN1ml0avr9UAbBWqG+UiyMGiz5sbyi6uOg3CjuUR5zRNw d+rSLJAwebmZtpAFF6INXoRW2AwrUvK3aD4xr71gzE0QfcjdEgBUKRN/pUN8zJUMNSkf 9o+ouxAzYgyPkkwDAndrpDERxeDLOsj+ppiz8+1Eqr0HyT/sbsG/PwNHUnwA9LmmmiEr 5j1A==
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=6eqMMcGn0CN50Ybvtz7MOv3ze2oYFbKpQaHbePRoBgA=; b=AzynyZ0yFQgF7U843JI5koP6TBQsn9QsY72RRKQcnMugXWazu97b+PeRbFP/GxqUWC ZjxatRopy5h19qZPESm3cxLU1VgE5WFmZ+3IRPxVoPbZcqmGHkDZ551JmbVK72KV47zz +MhzSlKzfiuBb6z3t0pz1aIj954DqpCzjKKQGb67n21U/afuGPCwL+H8PZcxlRfS5fdX I/8B0Z0pnosIzrHJ7DBR75c1mUvfDt8iGeGDcv+/YKxIDnmlM9FDe25VQO0EtFUVSpZJ D5O2RIJe9lh7Veetpsk684vSFOC3BZVtOG3fBtb/p9Ne46WhgShykjewOcBDmp6OdzTI n9FQ==
X-Gm-Message-State: AOAM531J89BNpn0SR38nz89VxHkWghKNqSna5hVlZ6dARgta9MuKh8Hh RgUy2TyXBX/mvVXxOP9pb8oTa677wwx9IqkwOQJNd9DP4sw=
X-Google-Smtp-Source: ABdhPJwpWUhBWhpPvCVNkfn8gIXHsvi43CyyhvvQXVzIcbrP+eNK7RC6P5YqJCATzAIE+iB7HLKJRNR6l2WmR2cEtu4=
X-Received: by 2002:a25:1d43:: with SMTP id d64mr7825292ybd.380.1610133312922; Fri, 08 Jan 2021 11:15:12 -0800 (PST)
MIME-Version: 1.0
References: <160996950953.25754.14270013028683006869@ietfa.amsl.com> <20210107231819.GO93151@kduck.mit.edu>
In-Reply-To: <20210107231819.GO93151@kduck.mit.edu>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 8 Jan 2021 13:14:46 -0600
Message-ID: <CAKKJt-f3n-T0Nx1daMJGNXVCw0Ds5-jUeUQBMh8mBUjc9wUE-g@mail.gmail.com>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, draft-ietf-quic-transport@ietf.org, WG Chairs <quic-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000028667b05b8686071"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9K56b22_OaABFlcEqTrxHsTGvW4>
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, 08 Jan 2021 19:15:16 -0000

Hi, Ben,

Top-posting here - I think one other point that is worth remembering, is
that the QUIC working group also has
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/, which
seems like a fine place for recommendations about deployment of specific
versions and withdrawal of other versions.

In my mind, there are two cases. Either

   - QUICv1 is "secure enough", so using it is OK even if QUICv2 would be
   better, or
   - QUIVv1 is not "secure enough", so downgrading will be a problem.

People can deploy QUIC using a variety of implementation strategies, but
given that the QUIC implementation is likely at least a library, and may be
a library bound to a specific application, it would be reasonable to say
"QUICv1 is not secure enough, so stop using QUICv1 as soon as possible",
and let implementers and deployers put out versions of applications that
aren't bound to QUICv1 at all.

(This discussion is slightly weird to me, because the last time I asked
about "QUICv2", the answer I got was that we're more likely to run for some
time with QUIv1 + extensions, but even then, my intention when QUIC was
chartered, was that deploying new versions should be orders of magnitude
than the universal deployment of a new version of TCP, for instance, and
withdrawing QUICv1 should be a lot easier than withdrawing TCPv4).

I'm sure everyone will Do The Right Thing, of course.

Best,

Spencer

On Thu, Jan 7, 2021 at 5:18 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Thanks everyone for the productive discussion.  It's clear that there's
> a lot of background available to those who participated in the previous
> WG discussions but (understandably!) did not make it into the document
> itself, and I appreciate the effort that was put in to help share that with
> me.
>
> Just to state it clearly, at no point has my position been that QUIC v1
> needs to be delayed until a complete version negotiation story exists.
> As this was a "discuss discuss", my goal was to obtain more information
> about the actual situation in order to confirm that there are no
> significant issues, since my interpretation of the text in the document
> itself left that possibility open.
>
> Attempting to summarize salient points:
>
> - the IETF is only currently defining bindings for HTTP over QUIC,
>   though other entities are free to define their own protocol over QUIC
>   at any time.
> - the only way currently defined to discover a QUIC endpoint to use as
>   server for a given HTTP service is the Alt-Svc header field, which
>   uses an ALPN value to indicate the protocol to use; it is perhaps not
>   fully nailed down that the ALPN value will be specific to a particular
>   version of QUIC but the ALPN vlaue probably will be specific to a
>   particular version of QUIC.
> - (SVCB is in the works, too, but may not be able to meet all the needs
>   for this purpose.)
> - Anyone doing non-HTTP or non-Alt-Svc is presumed to be configuring it
>   out of band and thus can provision the QUIC version to use along with
>   other provisioned information; in-band version negotiation is not
>   needed in that case.  If needed (e.g., we cannot build a secure
>   downgrade protection mechanism), this or similar techniques could be
>   used generically.
> - A downgrade protection mechanism solely in-band at the QUIC layer will
>   not be a complete solution for existing protocols that may also fall
>   back to a TCP binding (or new protocols that need to traverse networks
>   like the Internet that don't reliably pass UDP in the ways QUIC
>   needs).  New protocols over QUIC that are berift of such legacy would
>   have a complete solution, though.
> - There seems to be a desire to have only zero or one functional downgrade
>   prortection/version negotiation mechanism, globally.
> - (There is a corresponding desire to have zero non-functional downgrade
>   protection/version negotiation mechanisms.)
> - In accordance with the previous two points, it's expected that a
>   downgrade protection/version negotiation scheme, when specified, will
>   be in an IETF standards-track protocol specification.  (This document
>   does not necessarily have to be a new QUIC version, as I understand it,
>   though is not a blocking dependency until there is such a new version.)
> - In particular, we do *not* expect non-IETF QUIC versions to define
>   their own downgrade protection scheme.  They are expected to either
>   pick up the IETF one (when it exists) or just only use a single
>   version at a time, possibly with out of band configuration.
>
>
> I've attempted to update the text in the document to reflect my
> understanding of the current WG expectations (as summarized above), in a
> PR at https://github.com/quicwg/base-drafts/pull/4697 .
> Obviously, if my summary above is incorrect, that PR is not expected to
> be useful.
>
> In particular, since we do *not* expect or want non-IETF QUIC versions
> to be attempting to specify a downgrade protection scheme, the scope of
> the problem space seems sufficiently restricted that we have ample time
> to come up with something good and not find ourselves reacting to events
> out of our control.  The phrasing in the -33 suggests, at least to me,
> that *any* future version of QUIC, including one developed outside the
> IETF, might update version negotiation handling, which is where my
> perception of risk arose.
>
> I've tried to refrain from expounding on topics that are not actually
> relevant, but since I'm prone to doing so I may have let some sneak in
> anyway...
>
> Thanks again,
>
> Ben
>
>