Re: Stream0 Design Team Proposal

[Jana Iyengar <[e-mail]>]

>
> 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);
> }
>

That works as well. Though we'd have exhausted 1/8ths of the frame type
space, so I don't care much about saving bits here.

A thought occurs to me: a CRYPTO_HS frame with the fin bit set can be used
to indicate that the handshake is done.This could be used as a signal (aka
HANDSHAKE_DONE) to solve Marten's problem of a client rtxing a CFIN. Of
course, this would mean that this particular CRYPTO_HS frame would be
encrypted with a 1-RTT key... which *I think* is fine. What do you think?


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