Re: Stream0 Design Team Proposal
Kazuho Oku <kazuhooku@gmail.com> Wed, 23 May 2018 04:58 UTC
Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192E112DA0C for <quic@ietfa.amsl.com>; Tue, 22 May 2018 21:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7ZsAMYquEvT for <quic@ietfa.amsl.com>; Tue, 22 May 2018 21:58:38 -0700 (PDT)
Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 DC33F12025C for <quic@ietf.org>; Tue, 22 May 2018 21:58:38 -0700 (PDT)
Received: by mail-pl0-x233.google.com with SMTP id n10-v6so12254327plp.0 for <quic@ietf.org>; Tue, 22 May 2018 21:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CANatvzzS+T4HcddCemKF7bb1BmACFp=R4n+YMWkq7tnZaUXw4w@mail.gmail.com>
References: <CAKcm_gM39_x+==WwYfb5qeiqB_qxdAt0ow69V+s_Jny3Ek_hDw@mail.gmail.com> <CANatvzzS+T4HcddCemKF7bb1BmACFp=R4n+YMWkq7tnZaUXw4w@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 23 May 2018 13:58:37 +0900
Message-ID: <CANatvzzmLveA2N8qZ-Fa47G8Mzdv=k3+AdSeqvXCNm_0VNr1iA@mail.gmail.com>
Subject: Re: Stream0 Design Team Proposal
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>, Eric Rescorla <ekr@mozilla.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OPh4-xxw3wtoZ_fPeBWqkctQeA0>
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 04:58:41 -0000
PS. I forgot the link. The PoC is available at https://github.com/h2o/quicly/pull/8. 2018-05-23 13:57 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>: > 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 <ianswett=40google.com@dmarc.ietf.org>: >> 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: >> >> https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit >> >> >> A PR making the changes to the QUIC documents can be found at: >> >> https://github.com/quicwg/base-drafts/pull/1377 >> >> >> 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
- Stream0 Design Team Proposal Ian Swett
- Re: Stream0 Design Team Proposal Martin Thomson
- Re: Stream0 Design Team Proposal Subodh Iyengar
- Re: Stream0 Design Team Proposal Kazuho Oku
- Re: Stream0 Design Team Proposal Kazuho Oku
- Re: Stream0 Design Team Proposal Christian Huitema
- Re: Stream0 Design Team Proposal Jana Iyengar
- Re: Stream0 Design Team Proposal Kazuho Oku
- Re: Stream0 Design Team Proposal Mikkel Fahnøe Jørgensen
- Re: Stream0 Design Team Proposal Kazuho Oku
- Re: Stream0 Design Team Proposal Kazuho Oku
- RE: Stream0 Design Team Proposal Lucas Pardue
- Re: Stream0 Design Team Proposal Jana Iyengar
- Re: Stream0 Design Team Proposal Ted Hardie
- Re: Stream0 Design Team Proposal Eric Rescorla
- Re: Stream0 Design Team Proposal Ted Hardie
- Re: Stream0 Design Team Proposal Mikkel Fahnøe Jørgensen
- Re: Stream0 Design Team Proposal Eric Rescorla
- Re: Stream0 Design Team Proposal Jana Iyengar
- RE: Stream0 Design Team Proposal Mike Bishop
- RE: Stream0 Design Team Proposal Mike Bishop
- RE: Stream0 Design Team Proposal Mike Bishop
- Re: Stream0 Design Team Proposal Subodh Iyengar
- Re: Stream0 Design Team Proposal Kazuho Oku
- Re: Stream0 Design Team Proposal Jana Iyengar
- Re: Stream0 Design Team Proposal Eric Rescorla
- Re: Stream0 Design Team Proposal Martin Thomson
- Re: Stream0 Design Team Proposal Eric Rescorla
- Re: Stream0 Design Team Proposal Jana Iyengar
- Re: Stream0 Design Team Proposal Eric Rescorla