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