Re: Stream0 Design Team Proposal

Eric Rescorla <> Wed, 23 May 2018 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D719012E8C1 for <>; Wed, 23 May 2018 14:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, 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 wNpaldr6NjI0 for <>; Wed, 23 May 2018 14:34:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DAF212E865 for <>; Wed, 23 May 2018 14:34:13 -0700 (PDT)
Received: by with SMTP id a6-v6so20868072oia.2 for <>; Wed, 23 May 2018 14:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOdVUHzf8gWnZFslUTll7Yjza+EmuNGCWqgfa2kEjaI=; b=nVBvezl7RsGqR1iaLh1zBTEZ5rRRlKAcjn6ww8OVT3iGJ1wEOdpURv7MUzxujVulaX 5o9CaJiJoRIyWQqWSm4+m6Kqm/9y059Tjf8F3rM98JrknBR7drTOmzAgkynEIZ3+a0Bd 06q07MQIJqB5jRUY/OdoJMG9CwhVUgLwZr9KLYaerI41e9/IhFmXmHwu4UKZqn0gKiAF h0SITKYHkrS55RHpd27N3MffDjAp0/uMZCrjdB1HhqbJI9eKMJvXqVhYg5QiyQGM096d cn/ayHdHc4hZaAouYHHHm9hpzqRDx20wUD62WLgDDw4Cxa0+GDQG5SM/bELb5yyrnyLP /7pg==
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=nOdVUHzf8gWnZFslUTll7Yjza+EmuNGCWqgfa2kEjaI=; b=aBE3jfm9HiRBebzKZdxqDbmyrdgOraZF3tfIn3lA8+jV4oJLRdxPq7dBgioU3B/RkI GP7VmzkKxvxtfGtdZezfWjCuYAljYhY0fUOmrDTLyL+JRczCNSnMDR0JYovqR/MBAm+w A3RdzIKPFwrBAagaBtPvugYMdY05F0K2RjD+nXxICBcK9dsMyUybkN+SSBGNBbQZob7p Bo02TYZbJn3ZH7E0DdhTUo+BnlUBFQyomV//XjRBjXkCHTSEzP8O+rscK9FMtkhKmoe0 i4k7baEvFfNcxSJlT+PrFSuIz1UVcM4g/ALVl9O5WYyMzUxV4zoM84MRFKjvyf4VAo3N ykRg==
X-Gm-Message-State: ALKqPwcrb5rZT/glkd/vuD8ruC/trDYdcrNKBsQdlxzPaDECFKtO0K1Q 4BjMDAT84oFwDerLz5iW1dl6NNdxwplo1WoePOAVdg==
X-Google-Smtp-Source: AB8JxZqkC2R3L2AcBst5wlWg1xIBy9ouid45OASqN2yc8l5krnkh7aWn63SLzAL8MRRPHhQxj3t7HHgtfMgxSZDy0O4=
X-Received: by 2002:aca:c589:: with SMTP id v131-v6mr2669013oif.92.1527111252192; Wed, 23 May 2018 14:34:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:33:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Wed, 23 May 2018 14:33:31 -0700
Message-ID: <>
Subject: Re: Stream0 Design Team Proposal
To: Ted Hardie <>
Cc: Ian Swett <>, Eric Rescorla <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000b8415d056ce64bf1"
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 21:34:26 -0000

On Wed, May 23, 2018 at 2:00 PM, Ted Hardie <> wrote:

> On Wed, May 23, 2018 at 1:23 PM, Eric Rescorla <> wrote:
>> On Wed, May 23, 2018 at 12:42 PM, Ted Hardie <> wrote:
>>> Howdy,
>>> 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.
>> I believe you have misunderstood. In this document, there are no TLS
>> records and TLS handshake messages are carried in CRYPTO_HS frames.
>> Accordingly, padding is provided in the same fashion as QUIC ordinarily
>> does, i.e., using PADDING frames.
>> That's what I understood from the design document.  The point I'm making
> is that this actually a substantive change to the padding structure that
> was previously present (in TLS records), and the security analysis has to
> take that into account, so it (and similar things) should be described.

I don't think most of the analyses take padding into account, partly
because basically nobody pads, so nobody was assuming that padding came
from TLS.


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 unavailable.
> I'm not quite sure I follow what you are asking about here. In both cases,
> TLS sits on top of QUIC's reliable in-order deliver guarantees. Is the
> point you are making that formerly, if QUIC violated these guarantees, that
> would result in TLS handshake failure, whereas now it does not?
> This just related to the general point I was making above.  When the
> design shifts where it was getting a function, it would be helpful if it
> called it out more directly, to facilitate the analysis.
> regards,
> Ted
> -Ekr
>>> regards,
>>> Ted
>>> 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