Re: Stream0 Design Team Proposal

Kazuho Oku <> Wed, 23 May 2018 04:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 192E112DA0C for <>; Tue, 22 May 2018 21:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 s7ZsAMYquEvT for <>; Tue, 22 May 2018 21:58:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC33F12025C for <>; Tue, 22 May 2018 21:58:38 -0700 (PDT)
Received: by with SMTP id n10-v6so12254327plp.0 for <>; Tue, 22 May 2018 21:58:38 -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=TRYdwwvtagfugiXekzlTpYO+QSpHKqVVqHWyS/V8z1I=; b=AaJngRypGPIKAw12jdETwRzNUXeSa3zxy/q3BhlkGKFBkLerp3vdnUQ8q/Yl/feD3F GW2BZoc9iuiBqAEXjWeO05eNq9ynlhekVIK5FB9XvFYv5YFFIsAx1lSlWCcyLWRVnCOP XlPJQ5mprT/w9tQP2sOw0I77IbP1FpN1jkjNh3asBd7oUxYzlZLjQbPZSzLI6hEeZR4z qL0kX3gzwbZd8PkEkyrrrk1AB2ruez3rPewSEZ6JB9yXrnzjHfArsZJRo/soAuJe7LVe LiL7Qq+XKkcwEvpm3FQ8u36eHqilsEqcSm4rRK0WNxdyNC1+e6wRDvruyQpeKRMmuLJq ROtQ==
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=TRYdwwvtagfugiXekzlTpYO+QSpHKqVVqHWyS/V8z1I=; b=ZEmnJjFNtAfy0ZG6hkpZTxVIAhun5CAI7+3gcJVOJ1KzbtSYgcmUafllS9lw7WbPIW NZPlApbUqi/HdQdt9gflyGq8ppEvz0Hoy1G5piV9E4SdLiU7PBklNRt4E/hRxpjSuHfL 2DLGcgq1afkvBvDX3lNg23w0n7GyUa556o2XrVJupFw0v9MdtFBNkHPi5crw4WYSUmUP IFD8qCIpeLdW4q6Kbun8Y90jdGblHEsc00BMmjyKCieJsmFOjHotv8YRsrBw/6gjS8JT 03MHItrNhRqmHADdycD8+5wjbqImKOHbR/byjC51eYHeCIGdihaOwTKM+9065rhBIgsE DU4Q==
X-Gm-Message-State: ALKqPwdN7lj+mGIlbw3Wl4sRRN3XK6qP/fjhr7r6/ZKZMmU8uN4t2FMl LmgOkEym+DEf6gZbFwiSc8aXgHX2LmC60sQpHwY=
X-Google-Smtp-Source: AB8JxZrYxtg/TjzFbDu4BFujblMttQoDPlO1VaKx1yxU77i0xq0jClwMNYdyiPYiZlZjII9kzNUI92PJOEa+R2I0ZPI=
X-Received: by 2002:a17:902:8486:: with SMTP id c6-v6mr1392027plo.23.1527051518323; Tue, 22 May 2018 21:58:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1189:0:0:0:0 with HTTP; Tue, 22 May 2018 21:58:37 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Kazuho Oku <>
Date: Wed, 23 May 2018 13:58:37 +0900
Message-ID: <>
Subject: Re: Stream0 Design Team Proposal
To: Ian Swett <>
Cc: IETF QUIC WG <>, Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
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 04:58:41 -0000

PS. I forgot the link. The PoC is available at

2018-05-23 13:57 GMT+09:00 Kazuho Oku <>:
> FWIW, I am happy to tell you that I have a working PoC code for the
> proposed approach.
> On the QUIC side, I saw 2% (124 lines) increase in code size (more on
> that below). On the TLS side, I also saw 2% (175 lines) increase.
> However please look at the code size change especially on the QUIC
> side with grain of salt, as it is just a PoC.
> As expected, the key and encryption-level management on the QUIC side
> became very clean. Following are some of the design decisions I made
> as well as the outcomes:
> * All the interaction between picotls and quicly are accompanied by
> "epoch". Handshake messages are attributed with their epochs so that
> they do not get protected by the wrong key, or so that octets received
> under an incorrect encryption context cannot be misused.
> * All the traffic keys are governed by quicly (managing some traffic
> keys in TLS while managing PNE key in QUIC seems messy).
> * The Initial key is setup by quicly, wheeras other traffic keys are
> installed by picotls by calling a callback named
> update_traffic_key_cb. The callback accepts and installs 6 keys in
> total: for three levels (i.e. 0-RTT, handshake, 1-RTT) in two
> directions (send-side and receive-side).
> * Three PN spaces have their own AEAD encryption key. Initial PN and
> Handshake PN spaces have one aead decryption key each. Application PN
> space has up to two decryption keys: either for 0-RTT and 1-RTT or for
> two 1-RTT keys during key update.
> It was a pain to have a dedicated frame encoding for CRYPTO_HS, even
> though we can reuse (and I reused) the retransmission and reassembly
> logic of QUIC streams for the handshake flows. About a half of the
> code size increase comes from that (the other half comes from the
> added abstraction for having two contexts for the handshake). I would
> prefer reusing the STREAM frame encoding for the handshake data. We
> could possibly use a different base offset (i.e. for CRYPTO_HS frames
> we could use 0b00011XXX, whereas the STREAM frames use 0b00010XXX), as
> well as omitting the Stream ID field.
> Overall, now that I have a PoC, I am more confident that the proposed
> approach is the correct path forward. It *simplifies* the QUIC stack
> at the same time giving us better security properties as well as
> fixing various issues in the current design (as discussed in the
> design doc).
> 2018-05-23 10:30 GMT+09:00 Ian Swett <>:
>> 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
> --
> Kazuho Oku

Kazuho Oku