Re: Stream0 Design Team Proposal
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 23 May 2018 07:05 UTC
Return-Path: <mikkelfj@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 3BF3312DA07 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 00:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Nol0N7_MPW25 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 00:05:13 -0700 (PDT)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 E4E91124C27 for <quic@ietf.org>; Wed, 23 May 2018 00:05:12 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id e21-v6so4085882pgv.0 for <quic@ietf.org>; Wed, 23 May 2018 00:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=bmonkrGfmbB9M7himuKA0YiL8Sq4w+VtoWmn2TUWYrU=; b=YHuc3LHOi/fH60xuNdJok8vwFxSxaSZHbnerDVKfkX7/I1lOnytXZSMoUxizZT+rX0 dtzL5fClfxiorzz9cNaT6hif40rTRiAPR0oBS+QjDMLeKKXMsVfVWa6yZhIQjL/qoo7N pJyOgjGVoDHYkaevNS5bTjKXwjkGr2z/YcbhFcsnB/CSW3hCq9RxZzzeeJ1VT+NL9NY7 kMmaQsPgbTEq0VhnUI+rdONJ49Gn0yocMvhGjsHy0/2vDJHcoKRQrxnw90NcNMMPRVEE VmawiljlnUXRocffLr0N2kJTWpctLZLIWavQbjmnkuBMpBBOqTI3zPZ6AlkWeGiv6G9g U+Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=bmonkrGfmbB9M7himuKA0YiL8Sq4w+VtoWmn2TUWYrU=; b=ib6Y0SRto/WR66nV6jQMqHWTioTtSU3eK7j3x2m3z9M9tdNxOa7DurAZdrooQiA3bJ bTzcm7oY/V7l03/oaNUUloGmEKqXCDfmxf920sRHnu8kGM1a04E/Rtme2pU10gEggpgh 1tFt2x6g+SCAq0qWuGGm0Ed1Bu/vSYrt8cHXAXJuY2xZCpq2zkIg240kH0I/EDjmeYtL hBDjeMqHhrlZuhMMmJX/Nxr/gD7/8JtphBaO3czq5AT2S9lP6wBChUb6nFzVVQvmx5p8 QuB8sw0GAp4RGQ1mxiR/SBbqEfqdtPAj/wmvZCLnfZaL60clxBs6IZrSc88ZXKj041dp TWMA==
X-Gm-Message-State: ALKqPwfZBY7uu4C8PJjjrL2V4LyISj7cCBsw+7FKtPyGKBFp6LqWFJyy 9M4JMZqJm6PKyB7fJMo1AwWL/nJ+
X-Google-Smtp-Source: AB8JxZr+SUmD/EYtnUJmtdOpX8k0Ur0Y7Xem1ujUnb27IM1eSYbj9FV178o5up9MrT+jL4XYQGZQwA==
X-Received: by 2002:a62:1306:: with SMTP id b6-v6mr1682972pfj.58.1527059112338; Wed, 23 May 2018 00:05:12 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id h75-v6sm35936281pfh.148.2018.05.23.00.05.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 May 2018 00:05:11 -0700 (PDT)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Jana Iyengar <jri.ietf@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
CC: Eric Rescorla <ekr@mozilla.com>, IETF QUIC WG <quic@ietf.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Subject: Re: Stream0 Design Team Proposal
Thread-Topic: Stream0 Design Team Proposal
Thread-Index: AXdfQTVfdsMHO8uMeTvioDg7HZXh4ndxcEZUd0JPRHqxsKhcvw==
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Wed, 23 May 2018 07:05:07 +0000
Message-ID: <DB6PR10MB17663BEF867A18F421B796B2AC6B0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <CAKcm_gM39_x+==WwYfb5qeiqB_qxdAt0ow69V+s_Jny3Ek_hDw@mail.gmail.com> <CANatvzzS+T4HcddCemKF7bb1BmACFp=R4n+YMWkq7tnZaUXw4w@mail.gmail.com>, <CACpbDcddWz_i5GoNWYfDAdWKcX0_gOMiKk=ORVABGPE8+7c8Vw@mail.gmail.com>
In-Reply-To: <CACpbDcddWz_i5GoNWYfDAdWKcX0_gOMiKk=ORVABGPE8+7c8Vw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17663BEF867A18F421B796B2AC6B0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Uu-STnv1b7u-7DH7qZKnGdFJE6k>
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 07:05:16 -0000
I only had a quick pass over text but I like the concept and appreciate the rationales given. In particular it seems to decouple QUIC from TLS and it may be worth keeping as a design guideline. Consider a separate theoretical simplified handshake for embedded devices that always negotiate via ed/x25519 - would that fit cleanly in framing structure and handshake messaging? On the open issue of confirming client finished - I lean towards an explicit signal unless that leads to eternal ping pong. It takes out the guesswork and seen from a generic handshake perspective it may be more actionable without detailing why a key epoch was locked in. Mikkel ________________________________ From: QUIC <quic-bounces@ietf.org> on behalf of Jana Iyengar <jri.ietf@gmail.com> Sent: Wednesday, May 23, 2018 8:39:53 AM To: Kazuho Oku Cc: Eric Rescorla; IETF QUIC WG; Ian Swett Subject: Re: Stream0 Design Team Proposal 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<mailto: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<mailto: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