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 E83CC12DA03 for <>; Tue, 22 May 2018 21:58:01 -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 Wjq7rRTbF_RX for <>; Tue, 22 May 2018 21:57:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70F4F12025C for <>; Tue, 22 May 2018 21:57:59 -0700 (PDT)
Received: by with SMTP id c11-v6so12251657plr.5 for <>; Tue, 22 May 2018 21:57:59 -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=Co8FIQ+3ytPQcslH0OZQYSOCXGLwmRBrOBpuxhTlTlk=; b=XvuadnlAc1PrbwoMiGsLqLlN/bso1KOsmnr1KqX0KVwy8y5nBoqysnGcEJy0HLxyBE Pd9iUE/TH+pxaIV7gRmld0E0XPls8cx1iauKzq0FeyaK7MXFbDzcA/0/zfz1JZ5n2THE nqdaUv7GqO3ujyvsBqDQw1DsqNhT8aEN/Q4w1nftxI78s3j/tpqIRSG4ro1eyggwmcP2 bEU3CsG81irPfOP4fyKI4r7sZNHsjDFKN3+bd//Pb++G2iUGDHKtLzFhGlh/hEETqB89 fhEBCLWgXG/2XaAJqK+xvsdRtDNCMVDC64Ihp/O6ywmQwuk1rm9Bz84ji4chWjeM1ubV jYQQ==
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=Co8FIQ+3ytPQcslH0OZQYSOCXGLwmRBrOBpuxhTlTlk=; b=elOsskxai/TSgdxTazs3/t+Uoh/cRS0b/jpUIwGcZi/uB6ZhBwnxbI7J7qNP8QrA9P ivxCxzX47Z70zK0Qjzgm8Ct+rbeZEFNl5FdRyu8hfC9IsivhA4oRLG2a/o7MH0jZddui 0pG3SV3i71t8MfQnIRzaEzHOIpY/ZnMzcBFsbhV0t8OoTDsZb2x5yImLj23t6a58a23n 83nmvt8jyLP2epVdtxxU6TcsPBat1eg5swtyp9wH+bf6axm+JTZt5zvJlfqIbnnA7Voi igFxGJSlreQ9wDEWTWCtZFEWXwS5GdMTLfaYe1FOrCLDIB8pN/JVOics3Mur+GXOZlkU YavA==
X-Gm-Message-State: ALKqPwdaMyjz3DDYExOnU4uibngADVXY/4h8JC41wAt3BJRJldppEir9 G0yO31lHxmyzxEwP6xI7ukBsaO9GHHIgLynERZU=
X-Google-Smtp-Source: AB8JxZrofFmA/+wIrSol3G1WgjStICojVnagL+wgs1fA1gLrQQuHCPoWrdDOcjW3/S1CIGnaa+1ZOZyuYSsYLjz/Jek=
X-Received: by 2002:a17:902:b7c4:: with SMTP id v4-v6mr711048plz.224.1527051478871; Tue, 22 May 2018 21:57:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1189:0:0:0:0 with HTTP; Tue, 22 May 2018 21:57:58 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Kazuho Oku <>
Date: Wed, 23 May 2018 13:57:58 +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:02 -0000

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