Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

Ted Hardie <ted.ietf@gmail.com> Wed, 23 May 2018 20:17 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 381CD12D7E4 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 13:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ucEd3JYBGR0e for <quic@ietfa.amsl.com>; Wed, 23 May 2018 13:16:59 -0700 (PDT)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 A19F712D7E2 for <quic@ietf.org>; Wed, 23 May 2018 13:16:54 -0700 (PDT)
Received: by mail-ot0-x235.google.com with SMTP id l22-v6so26752435otj.0 for <quic@ietf.org>; Wed, 23 May 2018 13:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jm7ba8CcwSm1dv6wkVQBvMCNdqvXeN8UL12mhpAHvPk=; b=af1HkacNndKmXXzthiGjIVgkYWBMspSZPXO+lYM7iS9qy7UDdp2V2T8gWOXU2XvmKm A68au9ANfM73GSQ88q32YcV0qDrBQa1AKW0pbEpLp1eDsS7fnyC0xxNh4yoEQcukJya6 lMFPCxaVpE6BVA8u9k2LYjF7vJdxNCeo+MtpnwM0PrDxdLxFdW9PXiapxmf/VSYvcKMT UWOj3EvGhltr2qD4eCTltYA336m7xupWLOSd5Uc5wWP4BUQWCkrY/Ec8HZIBMKV4xmBT BOjH0eNaXspNuitRtD173SYYlnvrsTFQvsCgtEKYoASMRUkHx7b2tRr28YchDc3RtmHu sarw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jm7ba8CcwSm1dv6wkVQBvMCNdqvXeN8UL12mhpAHvPk=; b=oTc/Jp/hFt1qqtyVpbNlmGGBhQzTABoaiOgEhwZYnKbUGFVbBN9nh8XyQTmcNLpB2W Msd3ILgtF3vqlSZYSYOs2G2ffBnUJh0LoFGPsAjOhUb4NlCqDp91KYE9v6yjSUpcS2ch siQ2ev4TSdVV4gxESGcJVvej7EIWVFf9mKOHITaoSRRaQE21OAvhaxKVVFmYNXd4oIYj w8gSu6e2bUIqfoOaaXnuhQEtPMzrMXTZZyhYoUHDpEytwL5+5zZ+cPiSmFoh4pJALNp5 AbKj+JDNH+/hf71B8yxsaob0dCEa1FhV8I91/MFYbs8LxBvmn4Tw2lmbjjQkpi7MlEtr v9mA==
X-Gm-Message-State: ALKqPwe0RAUFspGgOioKe9TZ2NjywEkbQrUpkYcdoancXXeCQ+6XdARe WltcaHdWwAsPsDoqLIirqnhPRcOG2zOVD81o8qJxlA==
X-Google-Smtp-Source: AB8JxZq6PTxEY+yVcFqQ6r6l4XVf9bVpjaaDTXchmv/pfiTSmUszoHE5/PpdwfKQv8nXhaA5uaoGRnckJWDxHdaC8yg=
X-Received: by 2002:a9d:3fda:: with SMTP id i26-v6mr2542375ote.18.1527106613665; Wed, 23 May 2018 13:16:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:4399:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:16:23 -0700 (PDT)
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 23 May 2018 13:16:23 -0700
Message-ID: <CA+9kkMA0QnSmvbGOktngU+B-eC7CJFXLicEZfxQga6m6Z+gJLQ@mail.gmail.com>
Subject: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003de303056ce5373a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9iBS2-qtizta2G6DFE5wC43_ZMA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 23 May 2018 20:17:09 -0000

The charter for the working group currently says:

This work will describe how the protocol uses TLS 1.3 for key negotiation
and will also describe how those keys are used to provide confidentiality
and integrity protection of both application data and QUIC headers.

It's easy to read that as saying the work should be constrained to use TLS
1.3 as provided.  If we read it that way, the design team proposal is
strictly speaking out of charter, because it requires the creation of not
just new APIs for TLS 1.3 but essentially a new formal analysis that the
security guarantees work when there is no record layer and where the
replacement has somewhat different facilities.

But the charter also says

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In particular,
because something is in the initial document set does not imply that
there is consensus around the feature or around how it is specified.

That argues that the community was willing to see serious change in
adopting this work and that this work falls within the kind of change that
was contemplated, even if happens to be across working groups.  Personally,
I think that means the design should be considered.

But I have grave concerns about the implications.  My back of the envelope
calculation is that this means at least one more cycle of specification and
interop will be required before we get back to where we are with draft -11,
and that estimate is because I'm in a hopeful mood that Sean and Eric can
move the required work in TLS along.  A more practical Ted would see this
as adding at minimum 6 months to the schedule.  The changes in TLS are also
large enough that I expect that the deployment time to see significant
penetration of the new libraries to be longer than it would be for the
previous design.   Call it 9 months, with 3 months of error bar.

During that time, the penetration of gQUIC outside Google does not seem
likely to slow.  If you want what QUIC has to offer now, you will take the
already available code and go.  For Web usages, there are some down sides
to that, and it may slow the eventual deployment of IETF QUIC.

But there are also down sides to all of the other protocols that would like
to use QUIC but have been told to wait for the completion of this effort.
We're likely to see DNS over HTTPS over QUIC instead of DNS over QUIC,
simply because the DOH transport docs will be done.  There are some
advantages there, but also disadvantages in enmeshing the HTTP and DNS
caching semantics.    There are also a number of groups who want to use
QUIC as a replacement for the WebRTC data channel (and some as the
substrate for media).  This additional delay will certainly cause some code
to be written that will either need extensive change or will bit rot (or
fork).  None of that is without costs, especially opportunity costs.

If the working group does decide to adopt this design, I believe part of
the milestone adjustment must be a serious consideration of delaying the
qpack and HTTP-specific work while the core transport is finished.  The
good news, I think this design could end up making the document separation
that requires much cleaner, as well as making how to use QUIC with other
application protocols much more obvious.

My thanks again for doing the work of bringing the design forward,