Re: Stream0 Design Team Proposal

[Kazuho Oku <[e-mail]>]

2018-05-23 15:39 GMT+09:00 Jana Iyengar <[e-mail]>:
> 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
> }

That's correct. Considering the fact that the handshake flows are
never closed, we could do something like below to preserve some more,
by swapping the bits used for offset and fin.

0x10-0x17: STREAM frame
0x18-0x1B: CRYPTO_HS frame

if (0x10 <= type && type <= 0x1c) {
    if (type <= 0x18) {
        streamID = varint_consume(frame);
        if (type & 0x04)
            fin = 1;
    }
    if (type & 0x02)
        length = varint_consume(frame);
    if (type & 0x01)
        offset = varint_consume(frame);
}

>
> 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-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