Re: Stream0 Design Team Proposal

[Jana Iyengar <[e-mail]>]

Fair enough. I think 0x18 is fine.

On Wed, May 23, 2018 at 4:55 PM, Eric Rescorla <[e-mail]> wrote:

> I'm with MT on this one. Bits in the handshake are comparatively cheap. I
> do think it's of *some* benefit to be able to use the STREAM frame parser,
> but that 0x18 hack seems to get us that.
>
> -Ekr
>
>
> On Wed, May 23, 2018 at 4:51 PM, Martin Thomson <[e-mail]>
> wrote:
>
>> I'm not a fan of micro-optimizations like this, especially when it means
>> taking space we don't need.
>>
>> We don't need ANY of the bits on the CRYPTO stream.  The savings for an
>> absent length and offset are marginal and not worth burning 8 frame types
>> on, and the stream never really ends.  So if we made it have a type of
>> 0x18, then you would run it through the same code and get the same result.
>>
>> On Wed, May 23, 2018 at 4:40 PM Jana Iyengar <[e-mail]> wrote:
>>
>> > 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 <[e-mail]>
>> 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=
>> [e-mail]>:
>> >> > 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-bflDRV6au
>> ojfJLkxddT93j6SwHY8/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
>>
>>
>