Re: Stream0 Design Team Proposal

Ted Hardie <> Wed, 23 May 2018 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E32D012AAB6 for <>; Wed, 23 May 2018 12:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IUK7JvBQVCLc for <>; Wed, 23 May 2018 12:43:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B3FD1277BB for <>; Wed, 23 May 2018 12:43:31 -0700 (PDT)
Received: by with SMTP id b130-v6so20598150oif.12 for <>; Wed, 23 May 2018 12:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RoKCJIWofmS7iqi5nr/nBhNlBRh+CuI7L+K37O9JjHU=; b=tILdCxeQgoXHZ9FHii/mSppU8828ACj6T6SYCWVGGAG9E0OCW/AQuVD+gjGqXOjZ8x 8JERoZCEYeGJ0BWNPCwhVau7qEQevx5O0KgIc0TeIv1ohelnw3hm6wC4Zvxa/5rggMKy HYdQx71QMDlzWhS/7yvNfjJKXDSXa2q0cknRlyY1g/o01/oEnLx0pAM3M2MkjlK/ObAg MDiDSsAMLlEI9HZAWvSPL9HP4R8dMcVR/VI/FGPd/3wozFMzd43jGpSai7/1E9ys6HKy yVgpqEFdotxXE4TQvlr741H9mci8U/wLcDXxGHrrD622cRL2PMYdKvUmotyw7oXmHjkb MjkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RoKCJIWofmS7iqi5nr/nBhNlBRh+CuI7L+K37O9JjHU=; b=hm277kFFLTPFK+6LZsGlyxnJ/0WhucmsZbepSngG+YnzDI5/ph2rWcj2cI89HFY+I/ /+x6TecepLi8qabyFqgIP0jhvVvfejyfpVaKvk8fq2fot+21sIFpH0aUSpArrLzwwSBw Z0+YuU/MIjHoJNae7M3hqz8JeCsZNhOwex0hir5jpGlppMEr/nIBmDKnC64p381a3YDZ Mm8CcAW/3OMs3QDQ6veY9MfoG7rx7PwEYj0dSVTpZe6h7Eh5SmIDc1gVEz6iN5KKICZN IX8cowzW795appQqPOs7ObN3VBPR+yK7j8hvmmHUAb8PEPhAV3tHCc0K0cWipQjHJtDE JaHQ==
X-Gm-Message-State: ALKqPwcWtGnnOl0J0yRZQOh3py8Ogh9YZcpeAf3zqCGxsTeI5ufN0+uo tdZ5wodX0jkqfxSBg5KyNnDgKNb93FHUMLcITko=
X-Google-Smtp-Source: AB8JxZpBT+0c+L3eI4aBcxYasvoqZ6JfzshYlxJvgKnEDcUXTO+D1HkE7P25RT5S5sSCINqRF9NEQTzA7c7p2AE/KS8=
X-Received: by 2002:aca:488d:: with SMTP id v135-v6mr846882oia.142.1527104610081; Wed, 23 May 2018 12:43:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:4399:0:0:0:0:0 with HTTP; Wed, 23 May 2018 12:42:59 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Hardie <>
Date: Wed, 23 May 2018 12:42:59 -0700
Message-ID: <>
Subject: Re: Stream0 Design Team Proposal
To: Ian Swett <>
Cc: IETF QUIC WG <>, Eric Rescorla <>
Content-Type: multipart/alternative; boundary="000000000000d1a2b1056ce4bfb5"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 19:43:34 -0000


Thanks for sharing the document.  I have a couple of detailed comments, and
then some high level comments which I will put into a separate email.

First, the document says this:

Though proper analysis is needed, it is not likely that the removal of the
TLS record layer will cause a security concern, because the security
properties provided by QUIC packets are identical to what have been
provided by TLS records.

I'm not sure that this is actually the statement we need to analyze,
though. We need to be sure that the security properties of TLS records used
in TCP packets are available in QUIC streams in QUIC packets using UDP as a
multiplexing layer. There appear to be some difference in where the
facilities the overall system provides that may require more description.
As an example, I think the way padding works in this proposal needs more
description. If I understand correctly, each TLS record is encrypted
separately and the presence or absence of padding is indicated by a
padding_length byte present in each record. That means the padding is
related to the record, not the packet; by removing the record layer and
using QUIC frames, though, we seem to have a different padding structure.
QUIC uses padding frames, not padding within other frame types which is
both conceptually and practically different. Similarly, I'd be interested
in more text on the interaction with precedence, since the loss of the
record layer means that the former guarantee that the record layer makes
records available in the order in which they were protected now seems to be

Secondly, I think the advantages of the different number spaces would be
present in many different designs, and I would a prefer that a proposal for
that be decoupled from the other pieces of this. At least to my
understanding, the attacks it mitigates are unrelated to the other stream 0
issues that this addresses.



On Tue, May 22, 2018 at 6:30 PM, Ian Swett <> wrote:

> *Dear QUIC WG,On behalf of the Stream 0 Design Team, I am pleased to
> report that we have consensus on a proposed approach to share with the WG.
> The DT's proposal will make QUIC and TLS work closer together and
> incorporates ideas from DTLS, but it does not use the DTLS protocol itself.
> The DT believes this solves the important open Stream 0 issues. The
> proposal will be a bit more invasive in TLS, but we believe it is the right
> long-term direction and several TLS stacks (BoringSSL, PicoTLS, NSS, and
> Mint) are willing and able to do the work necessary.. A number of stacks
> are currently working on implementations of this new approach, which we
> hope to have in time for the Interim meeting.A design document describing
> the overall approach can be found
> at:
> <>A
> PR making the changes to the QUIC documents can be found
> at:
> <>A few design details did not
> have clear consensus, but it was felt it would be better to discuss those
> in the wider WG than delay the design team.  A consistent choice was made
> in the PR and these issues are mentioned in Appendix B of the design doc.As
> always, comments and questions welcome. That said, this is a big PR and we
> recognize that some editorial work is going to be needed before merging. In
> the interest of letting people follow along, and to keep github from
> falling over, we ask people to keep discussion on the mailing list and
> refrain from making PR comments.See you in Kista!*
> Ian and Eric