Re: Stream0 Design Team Proposal
Jana Iyengar <jri.ietf@gmail.com> Wed, 23 May 2018 06:39 UTC
Return-Path: <jri.ietf@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 0E264124B0A for <quic@ietfa.amsl.com>; Tue, 22 May 2018 23:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 to4lbWCM6isg for <quic@ietfa.amsl.com>; Tue, 22 May 2018 23:39:55 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 BDE2C124BFA for <quic@ietf.org>; Tue, 22 May 2018 23:39:54 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id p124-v6so21486401iod.1 for <quic@ietf.org>; Tue, 22 May 2018 23:39:54 -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=AZtCJM1Z+BKUOVA+t4ilfqriEfCZJh/r4PBubjQLrrU=; b=h5AhR5JqA6Kf+CWdudWUbn42jcoUVkRuvKa+ZFPHy+M8YwwhxpaUdi2sYxwVuqYJsQ 5GhcAOuO+0xTLlg5XYYiYQ9Vlh4v3BVZtXZkxnfEYqRzwjCymISlFrGBS21AgQu58vhY x0X6GSVDTa3X2h+BqyUwpSIYhVURnxAKsxJBtQ8rGkQ2i8cm8E5jEjekD0eErHFmviyZ fbQlCAPngId+EKJ1kiD+WUQoLDvOCQOTiwwgLSHtbp8WQC1SwYwwkb0ywWt+pZzbrHkM c7cFtIEEvTCLK88JDpwrV5UVpU9ER5yn8GdE2cM02KoqBi06krjx+8W4y7SrAC1VQcw0 Wh3A==
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=AZtCJM1Z+BKUOVA+t4ilfqriEfCZJh/r4PBubjQLrrU=; b=DYMgxvWMBCEhqrEzqxRJ1tp8cL3iXHeshCiFfR7Q3ViCqWRbFGemsDeM1onvim9X7h IdZAY20YvPy+b/LuAXDVRYI1wmLTXss3j5M3RZPkEOQoN8Ba+owf0KOxlulihO7EK+9n CC4LGNEcSKaJdooESz9BltF5bzYlWSMziCNi9pTUXjX26NzwIdTR2qEC+oN0t0P8+q2e j1LL6EGL4mSSTO5vMyQgAr3+5jlZdrc07GwXhztNhAqvUP8j+t+VjdYtPKJcnHiHRtVQ Gx7P3lRoporVvbsLX0ij920e2nWiloXAOn2B3bMg0QwtOBDZ+gua9CyVMxpYN80qa6hF Omeg==
X-Gm-Message-State: ALKqPweUA8FqxrZsHxYK4BMMJe1FmWDX8xB7w++8cirSDtCYqAYa5Tr6 mATAkjAfPPAmGkCoEwHBFYilwZjCJGdD4r6eW2vggQ==
X-Google-Smtp-Source: ADUXVKJczOpdj7Ygu8qN/2UV6We0bpBheX39E/Go1m161wwOcH6Uw1IRWLZH/mqbmhcf29aauHf/s2mbSumzr/tyv+s=
X-Received: by 2002:a6b:88e3:: with SMTP id s96-v6mr1338921ioi.45.1527057593947; Tue, 22 May 2018 23:39:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:27d4:0:0:0:0:0 with HTTP; Tue, 22 May 2018 23:39:53 -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: Jana Iyengar <jri.ietf@gmail.com>
Date: Tue, 22 May 2018 23:39:53 -0700
Message-ID: <CACpbDcddWz_i5GoNWYfDAdWKcX0_gOMiKk=ORVABGPE8+7c8Vw@mail.gmail.com>
Subject: Re: Stream0 Design Team Proposal
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Eric Rescorla <ekr@mozilla.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000705907056cd9cd89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g_em-EST1jWfEhm0XnZuqJ6AqAA>
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 06:39:58 -0000
Thank you for your implementation and your report -- this is terrific and helpful! On your note about CRYPTO_HS frames, I think your idea is clever. Just to ensure that I am understanding it correctly, I believe you're proposing defining: 0x10 - 0x17: STREAM frame 0x18 - 0x1F: CRYPTO_HS frame We can the same frame format for CRYPTO_HS as STREAM except that CRYPTO_HS will not have the stream ID field. This means an implementation handling these frames can reuse the stream machinery with a small change to parse the header bits as follows: if (type & 0x10) { // STREAM or CRYPTO_HS frame if (type & 0x08) streamID = varint_consume(frame); if (type & 0x04) offset = varint_consume(frame); if (type & 0x02) length = varint_consume(frame); if (type & 0x01) fin = 1; read body if present } On Tue, May 22, 2018 at 9:57 PM, Kazuho Oku <kazuhooku@gmail.com> wrote: > 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 > >
- 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