Re: Stream0 Design Team Proposal

[Eric Rescorla <[e-mail]>]

Hi folks,

I have implemented the proposal from the Stream 0 DT in Minq, and have
interop with Quicly in the 1-RTT mode. This went in quite cleanly at
the cost of probably a day of programming. The code size is about
the same (slight reduction but that's before I cleand up old code
and added some things I know I need).


Mint already had a separated record layer, so on the Mint side, this
was mostly a matter of making that API public, i.e.,

- Making it a Golang interface so I could have multiple
  implementations
- Cleaning up the interface a bit (mostly removing APIs that only DTLS
  uses).
- Adding a way for Minq to add its own record layer implementation
- Adding an API to override the TLS HKDF label prefix

Here's the definition of RecordLayer, with some unnecessary APIs that
I haven't cleaned up yet removed.

  type RecordLayer interface {
        // Install a new TLS key at the record layer
      Rekey(epoch Epoch, factory AeadFactory, key []byte, iv []byte) error

        // Reset back to the "cleartext" record layer
      ResetClear(seq uint64)

        // I'm never going to want to read at this level again
      DiscardReadKey(epoch Epoch)

        // Read a record
      ReadRecord() (*TLSPlaintext, error)

        // Write a record
      WriteRecord(pt *TLSPlaintext) error

        // What is the current Epoch (saves bookkeeping in Mint)
      Epoch() Epoch
  }

The way this works is that Minq installs two RecordLayer objects, one
in each direction [0]. Each one has one active epoch that it expects
to read or write from, and the epoch has an associated queue.

So, for instance, on the server side when Minq receives an Initial
packet, it decrypts it and then stuffs the CRYPTO_HS frames into the
queue associated with epoch 0. It then calls Mint.handshake() which
does:

  Rx: ReadRecord() -> ClientHello
  Tx: WriteRecord(ServerHello)
  Tx: Rekey(epoch = 2 [Handshake)
  Tx: WriteRecord(EncryptedExtensions)
  Tx: WriteRecord(Certificate)
  Tx: WriteRecord(CertificateVerify)
  Tx: WriteRecord(Finished)
  Tx: Rekey(epoch = 3 [Application Data])
  Rx: Rekey(epoch = 2 [Handshake)

This queues up two "flows" of data, corresponding to the Initial and
Handshake encryption levels. Minq is then responsible for sending
these flows in their own packet types with the appropriate keys. When
Mint calls ReadRecord() again, it's reading out of the Handshake input
queue (due to the Rekey that's the last operation).

This is still a bit too messy to put up on Github, but I should have
something up in time for Kista.

-Ekr

[0] One might want to have ReadRecordLayer and WriteRecordLayer, but I
was lazy.


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