Subject: Stream0 Design Team Proposal

From: Ian Swett <[email-masked]>
Date: Tue, 22 May 2018 21:30:45 -0400

*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
<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
<https://github.com/ekr/base-drafts/pull/29>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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 13:00:40 +1000

First of all, thanks to the design team for the work they have done.  I
haven't digested everything yet, but I think that I have a good sense of
the shape of the proposal.

Overall, this looks like a workable design.  It's a lot more invasive of
the cryptographic handshake implementation than I had thought people were
willing to stomach originally.  But it's clear that we've run into problems
with the current, more abstract API and this is a fairly natural way to
split TLS.  I've spent a little time thinking about how this might be
implemented and I think that it's not going to be *too* painful.  The proof
will be in the pudding there though.

In looking at the PR, I really appreciate seeing all the changes together.
BTW, the link above points to the wrong PR, so be careful (it appears to
have the same content, but that's not guaranteed).  The actual PR is here:
https://github.com/quicwg/base-drafts/pull/1377

I've pushed a branch to the main repo so that you can preview the entire
document set: https://quicwg.github.io/base-drafts/stream0/

It seems like there are some core changes here and a bunch of separable or
at least secondary changes.  I'm sure that each one has its own
justification, but that isn't always clear. The following changes seem like
they are separable:

* The use of separate packet number spaces
* The Retry packet changes (and NEW_TOKEN)
* EMPTY_ACK
* The TLS extension for flow control

Right now, some of these appear to be entirely gratuitous.  I'd like to get
to the bottom of each before we continue.

At a minimum, the PR we land first should include just the core changes.
As you say, reviewing a monster PR like this will only make GitHub weep
unicorns, but we might be able to cut this into smaller pieces.

On Wed, May 23, 2018 at 11:31 AM Ian Swett <ianswett=
[email-masked]> wrote:

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

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 23 May 2018 03:26:01 +0000

As an implementor of fizz, I support this design and am willing to implement this as well.

While this is a change in the API that TLS classically exposes, I think this is the right tradeoff because it helps make things way more explicit which will prevent several other bugs from happening in the future.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Tuesday, May 22, 2018 8:00:40 PM
To: Ian Swett
Cc: [email-masked]; QUIC WG
Subject: Re: Stream0 Design Team Proposal

I've pushed a branch to the main repo so that you can preview the entire
document set: https://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_base-2Ddrafts_stream0_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=ususmtxI3BTaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&e=

> A design document describing the overall approach can be found at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j6SwHY8_edit&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=jDNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wVGg&e=

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 13:57:58 +0900

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=[email-masked]>:
> 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
> willing and able to do the work necessary.. A number of stacks are currently
> time for the Interim meeting.
>
>
> 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

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 13:58:37 +0900

PS. I forgot the link. The PoC is available at
https://github.com/h2o/quicly/pull/8.

-- 
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 May 2018 22:29:12 -0700

I like the proposal. In particular, I really like the encryption of
handshake packets with the handshake key, as it does close a number of
avenues for attacks. And I like that it solves the "ack promotion" issue
that I was complaining against for some time. Turns out that in the
current draft, it is very hard to contain that problem if you enable
client auth.

On the other hand, I agree with Martin that a lot of the additions to
transmission recovery should be moved to separate PRs. I am not
enthusiastic with the EMPTY ACK mechanism, or with the proposed
"implicit acknowledgement" of a lower crypto stream by a higher level
ack. In any case, starting as simple as possible would help having the
first implementations and tests.

On 5/22/2018 8:26 PM, Subodh Iyengar wrote:
> While this is a change in the API that TLS classically exposes, I
> think this is the right tradeoff because it helps make things way more
> explicit which will prevent several other bugs from happening in the
> future.
>
>
> Subodh
>
> ------------------------------------------------------------------------
> *From:* QUIC <[email-masked]> on behalf of Martin Thomson
> <[email-masked]>
> *Sent:* Tuesday, May 22, 2018 8:00:40 PM
> *To:* Ian Swett
> *Cc:* [email-masked]; QUIC WG
> *Subject:* Re: Stream0 Design Team Proposal
>  
> document set:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_base-2Ddrafts_stream0_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=ususmtxI3BTaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&e=
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 22 May 2018 23:39:53 -0700

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 <[email-masked]> wrote:

> 2018-05-23 10:30 GMT+09:00 Ian Swett <ianswett=[email-masked]
> >:
> > Dear QUIC WG,
> >
> >
> have
> proposal
> would
> and

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 15:57:04 +0900

2018-05-23 15:39 GMT+09:00 Jana Iyengar <[email-masked]>:
> these frames can reuse the stream machinery with a small change to parse the
> header bits as follows:
>

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

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 23 May 2018 07:05:07 +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 <[email-masked]> on behalf of Jana Iyengar <[email-masked]>
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:

On Tue, May 22, 2018 at 9:57 PM, Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:
FWIW, I am happy to tell you that I have a working PoC code for the
proposed approach.

--
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 16:21:21 +0900

2018-05-23 16:05 GMT+09:00 Mikkel Fahnøe Jørgensen <[email-masked]>:
> 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?

I think that is a very good question, and I believe that the answer is yes.

IIUC, the goal of any handshake protocol is to switch to a encrypted
bidirectional channel. The difference between the protocols is how
many intermediate encryption levels they will have (In TLS 1.3, we
have one intermediate level. There were no intermediate levels in the
prior versions of TLS).

If we are to adopt a handshake protocol that does not have any
intermediate encryption level, we can support it simply by ditching
the Handshake level.

If we are to adopt a handshake protocol that has multiple intermediate
levels, we can support that by splitting Handshake level into multiple
levels.

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

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 18:13:52 +0900

2018-05-23 14:29 GMT+09:00 Christian Huitema <[email-masked]>:
> that I was complaining against for some time. Turns out that in the current
> draft, it is very hard to contain that problem if you enable client auth.
>
>
> transmission recovery should be moved to separate PRs. I am not enthusiastic
> with the EMPTY ACK mechanism, or with the proposed "implicit
> acknowledgement" of a lower crypto stream by a higher level ack.

At the moment I do not have a strong opinion on the Empty ACK mechanism.

However, regarding how we close the Initial and Handshake contexts, my
preference goes to using implicit ACKs (i.e. use the successful
receipt of a packet that is protected under a higher level of
encryption key as the signal) rather than explicitly ACKing the last
flight of data.

As I see, there are two downsides in the Explicit ACKing approach.

* Explicit ACKing requires sending two additional packets during the
handshake, which means that we would have more AES operations plus
somewhere around 60 bytes of overhead on the wire.
* Explicit ACKing requires more signaling from the TLS stack. In case
of implicit ACKing, the TLS stack need to only provide the AEAD
contexts and the messages, whereas in case of explicit ACKing, the TLS
stack also needs to provide a signal indicating the end of the
transmission at each encryption level.

The downside of the implicit ACKing approach is that the server needs
to signal the termination of the Handshake context using a special
frame sent using a 1-RTT packet.

But even taking that into consideration, I think that implicit ACKing
is still easier to implement, considering the need for the additional
signal in the explicit ACK case that have been described above.

> In any
> case, starting as simple as possible would help having the first
> implementations and tests.
>
>
> While this is a change in the API that TLS classically exposes, I think this
> is the right tradeoff because it helps make things way more explicit which
> will prevent several other bugs from happening in the future.
>
>
> Subodh
>

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 23 May 2018 09:40:20 +0000

Hi Martin,

>document set: https://quicwg.github.io/base-drafts/stream0/

Thanks but please note that the diff URLS on that page are broken, they don't provide the IETF tools with the correct version to diff, which makes it look like the stream 0 changes are minimal.

In the meantime, here are correct URLs that people can use to view the diffs:

Transport: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&url2=https://quicwg.github.io/base-drafts/stream0/draft-ietf-quic-transport.txt
TLS: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&url2=https://quicwg.github.io/base-drafts/stream0/draft-ietf-quic-tls.txt
Recovery: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&url2=https://quicwg.github.io/base-drafts/stream0/draft-ietf-quic-recovery.txt
HTTP: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&url2=https://quicwg.github.io/base-drafts/stream0/draft-ietf-quic-http.txt

Regards
Lucas

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 11:46:11 -0700

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 May 2018 12:42:59 -0700

Howdy,

Thanks for sharing the document.  I have a couple of detailed comments, and
then some high level comments which I will put into a separate email.

First, the document says this:

Though proper analysis is needed, it is not likely that the removal of the
TLS record layer will cause a security concern, because the security
properties provided by QUIC packets are identical to what have been
provided by TLS records.

I'm not sure that this is actually the statement we need to analyze,
though. We need to be sure that the security properties of TLS records used
in TCP packets are available in QUIC streams in QUIC packets using UDP as a
multiplexing layer. There appear to be some difference in where the
facilities the overall system provides that may require more description.
As an example, I think the way padding works in this proposal needs more
description. If I understand correctly, each TLS record is encrypted
separately and the presence or absence of padding is indicated by a
padding_length byte present in each record. That means the padding is
related to the record, not the packet; by removing the record layer and
using QUIC frames, though, we seem to have a different padding structure.
QUIC uses padding frames, not padding within other frame types which is
both conceptually and practically different. Similarly, I'd be interested
in more text on the interaction with precedence, since the loss of the
record layer means that the former guarantee that the record layer makes
records available in the order in which they were protected now seems to be
unavailable.

Secondly, I think the advantages of the different number spaces would be
present in many different designs, and I would a prefer that a proposal for
that be decoupled from the other pieces of this. At least to my
understanding, the attacks it mitigates are unrelated to the other stream 0
issues that this addresses.

regards,

Ted

On Tue, May 22, 2018 at 6:30 PM, Ian Swett <
ianswett=[email-masked]> wrote:

>
>
>
>
>
>
>
> *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.
> hope to have in time for the Interim meeting.A design document describing
> the overall approach can be found

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 13:23:50 -0700

On Wed, May 23, 2018 at 12:42 PM, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> Thanks for sharing the document.  I have a couple of detailed comments,
> and then some high level comments which I will put into a separate email.
>
> both conceptually and practically different.
>

I believe you have misunderstood. In this document, there are no TLS
records and TLS handshake messages are carried in CRYPTO_HS frames.
Accordingly, padding is provided in the same fashion as QUIC ordinarily
does, i.e., using PADDING frames.

Similarly, I'd be interested in more text on the interaction with
> precedence, since the loss of the record layer means that the former
> guarantee that the record layer makes records available in the order in
> which they were protected now seems to be unavailable.
>

I'm not quite sure I follow what you are asking about here. In both cases,
TLS sits on top of QUIC's reliable in-order deliver guarantees. Is the
point you are making that formerly, if QUIC violated these guarantees, that
would result in TLS handshake failure, whereas now it does not?

-Ekr

> regards,
>
>
> Ted
>
>
>
>
>
> On Tue, May 22, 2018 at 6:30 PM, Ian Swett <ianswett=40google.com@dmarc.
> ietf.org> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>> at:https://docs.google..com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 May 2018 14:00:14 -0700

On Wed, May 23, 2018 at 1:23 PM, Eric Rescorla <[email-masked]> wrote:

>> Though proper analysis is needed, it is not likely that the removal of
>> the TLS record layer will cause a security concern, because the security
> That's what I understood from the design document.  The point I'm making
is that this actually a substantive change to the padding structure that
was previously present (in TLS records), and the security analysis has to
take that into account, so it (and similar things) should be described.

This just related to the general point I was making above.  When the design
shifts where it was getting a function, it would be helpful if it called it
out more directly, to facilitate the analysis.

regards,

Ted

-Ekr
>
>
>
>> regards,
>>
>>
>> Ted
>>
>>
>>
>>
>>
>> On Tue, May 22, 2018 at 6:30 PM, Ian Swett <ianswett=[email-masked]
>> etf.org> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 23 May 2018 17:20:08 -0400

As an example of things to consider, padding is probably a fair point. From
a practical perspective, padding could be seen as a pain from older crypto
formats that needs to be dealt with in TLS while the crypto primitives of
QUIC already has an answer to this problem.

But if TLS messages contain encryption primitives beyond what QUIC provides
in early handshake that assumption breaks down while the QUIC crypto is
still weak. For example concerning the encoding of key exchange parameters.
So at the very least it must be stated that this is not an issue and why it
is not issue.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 14:33:31 -0700

> take that into account, so it (and similar things) should be described.

I don't think most of the analyses take padding into account, partly
because basically nobody pads, so nobody was assuming that padding came
from TLS.

-Ekr

> This just related to the general point I was making above.  When the
> design shifts where it was getting a function, it would be helpful if it
> called it out more directly, to facilitate the analysis.
>
> regards,
>
> Ted
>
> -Ekr
>>
>>
>>
>>> regards,
>>>
>>>
>>> Ted
>>>
>>>
>>>
>>>
>>>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 14:50:05 -0700

Ted,

I agree that we should be careful and describe differences in detail where
they exist before making any conclusions about a security analysis. Perhaps
we ought to bring this in front of the tlswg and make sure that folks there
get a chance to poke holes in this proposal.

That said, I don't believe your mapping from records to frames is right. As
I see it, the equivalent of a TLS record in this proposal is a QUIC packet.
Both are encrypted similarly, and both contain pieces of or one or multiple
messages. Padding in TLS is present within the records but outside
messages. Equivalently, padding in this proposal is present within packets
but outside frames carrying TLS messages.

- jana

On Wed, May 23, 2018 at 2:20 PM, Mikkel Fahnøe Jørgensen <[email-masked]
> wrote:

> As an example of things to consider, padding is probably a fair point.
> From a practical perspective, padding could be seen as a pain from older
> crypto formats that needs to be dealt with in TLS while the crypto
> primitives of QUIC already has an answer to this problem.
>
> But if TLS messages contain encryption primitives beyond what QUIC
> provides in early handshake that assumption breaks down while the QUIC
> crypto is still weak. For example concerning the encoding of key exchange
> parameters. So at the very least it must be stated that this is not an
> issue and why it is not issue.
>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 May 2018 22:14:29 +0000

While a HS_DONE frame sent under 1-RTT would simplify some things, I'm not sure that it's required.  There's a very clear synchronization point which already exists.

The client can't send 1-RTT messages until it has sent Client Finished.  The server can send, but not process, 1-RTT messages prior to receiving Client Finished.  (This is a spec requirement rather than a crypto limitation, however, so a buggy server might violate it.)  Thus, an ACK for any 1-RTT packet from the client implicitly acknowledges the client's entire handshake.  Receipt of any 1-RTT packet from the client implicitly acknowledges the server's entire handshake.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Kazuho Oku
Sent: Wednesday, May 23, 2018 2:14 AM
To: Christian Huitema <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Stream0 Design Team Proposal

2018-05-23 14:29 GMT+09:00 Christian Huitema <[email-masked]>:
> avenues for attacks. And I like that it solves the "ack promotion" 
> issue that I was complaining against for some time. Turns out that in 
> the current draft, it is very hard to contain that problem if you enable client auth.
>
>
> "implicit acknowledgement" of a lower crypto stream by a higher level ack.

However, regarding how we close the Initial and Handshake contexts, my preference goes to using implicit ACKs (i.e. use the successful receipt of a packet that is protected under a higher level of encryption key as the signal) rather than explicitly ACKing the last flight of data.

* Explicit ACKing requires sending two additional packets during the handshake, which means that we would have more AES operations plus somewhere around 60 bytes of overhead on the wire.
* Explicit ACKing requires more signaling from the TLS stack. In case of implicit ACKing, the TLS stack need to only provide the AEAD contexts and the messages, whereas in case of explicit ACKing, the TLS stack also needs to provide a signal indicating the end of the transmission at each encryption level.

The downside of the implicit ACKing approach is that the server needs to signal the termination of the Handshake context using a special frame sent using a 1-RTT packet.

But even taking that into consideration, I think that implicit ACKing is still easier to implement, considering the need for the additional signal in the explicit ACK case that have been described above.

> explicit which will prevent several other bugs from happening in the future.
>
>
> Subodh
>
> First of all, thanks to the design team for the work they have done.  
> I haven't digested everything yet, but I think that I have a good 
> sense of the shape of the proposal.
>
> Overall, this looks like a workable design.  It's a lot more invasive 
> of the cryptographic handshake implementation than I had thought 
> people were willing to stomach originally.  But it's clear that we've 
> run into problems with the current, more abstract API and this is a 
> fairly natural way to split TLS.  I've spent a little time thinking 
> about how this might be implemented and I think that it's not going to 
> be *too* painful.  The proof will be in the pudding there though.
>
> In looking at the PR, I really appreciate seeing all the changes together..
> BTW, the link above points to the wrong PR, so be careful (it appears 
> to have the same content, but that's not guaranteed).  The actual PR is here:
> I've pushed a branch to the main repo so that you can preview the 
> entire document set:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_
> base-2Ddrafts_stream0_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mH
> twg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=ususmtxI3B
> TaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&e=
>
> It seems like there are some core changes here and a bunch of 
> separable or at least secondary changes.  I'm sure that each one has 
> its own justification, but that isn't always clear. The following 
> changes seem like they are separable:
>
> Right now, some of these appear to be entirely gratuitous.  I'd like 
> to get to the bottom of each before we continue.
>
> As you say, reviewing a monster PR like this will only make GitHub 
> weep unicorns, but we might be able to cut this into smaller pieces.
>
> proposal will make QUIC and TLS work closer together and incorporates 
> ideas from DTLS, but it does not use the DTLS protocol itself.
>
>
> 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.
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_d
> ocument_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j6SwHY8_edit&d=DwIBaQ
> &c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJ
> nPntLYw1T0_NEMiHYSM0Q_u1JA&s=jDNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wV
> Gg&e=
>
>
> 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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 May 2018 22:23:20 +0000

I also think these two pieces are not inextricably bound together:

  *   Moving from Stream 0 to CRYPTO frames
  *   Removing the TLS record layer and using the TLS keys directly in QUIC packet protection

…though both of these interact pretty closely with the separate packet number spaces.

So I think that’s roughly six PRs we should expect to see out of the design team’s proposal.  A few of them have dependencies on each other, but they seem mostly separable.  It sounds like several of them have consensus in the design team, but not all of them, and it would be good to be able to discuss them separately.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Martin Thomson
Sent: Tuesday, May 22, 2018 8:01 PM
To: Ian Swett <ianswett=[email-masked]>
Cc: [email-masked]; QUIC WG <[email-masked]>
Subject: Re: Stream0 Design Team Proposal

First of all, thanks to the design team for the work they have done.  I haven't digested everything yet, but I think that I have a good sense of the shape of the proposal.

Overall, this looks like a workable design.  It's a lot more invasive of the cryptographic handshake implementation than I had thought people were willing to stomach originally.  But it's clear that we've run into problems with the current, more abstract API and this is a fairly natural way to split TLS.  I've spent a little time thinking about how this might be implemented and I think that it's not going to be *too* painful.  The proof will be in the pudding there though.

BTW, the link above points to the wrong PR, so be careful (it appears to have the same content, but that's not guaranteed).  The actual PR is here:

I've pushed a branch to the main repo so that you can preview the entire document set: https://quicwg.github.io/base-drafts/stream0/

It seems like there are some core changes here and a bunch of separable or at least secondary changes.  I'm sure that each one has its own justification, but that isn't always clear. The following changes seem like they are separable:

* EMPTY_ACK

Right now, some of these appear to be entirely gratuitous.  I'd like to get to the bottom of each before we continue.

As you say, reviewing a monster PR like this will only make GitHub weep unicorns, but we might be able to cut this into smaller pieces.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 May 2018 22:26:35 +0000

Christian, can you expand on why you dislike the EMPTY_ACK?  Being able to say "I've received some packets from you, but am unable to process any of them because I'm missing some handshake data" seems like a useful way to short-circuit timeouts on clients.  It also doesn't commit the server to holding any state - IIUC, a server could form a packet containing an EMPTY_ACK and then discard its internal state until it gets the retransmitted (or delayed) Initial packet.

From: QUIC <[email-masked]> On Behalf Of Christian Huitema
Sent: Tuesday, May 22, 2018 10:29 PM
To: [email-masked]
Subject: Re: Stream0 Design Team Proposal

I like the proposal. In particular, I really like the encryption of handshake packets with the handshake key, as it does close a number of avenues for attacks. And I like that it solves the "ack promotion" issue that I was complaining against for some time. Turns out that in the current draft, it is very hard to contain that problem if you enable client auth.

On the other hand, I agree with Martin that a lot of the additions to transmission recovery should be moved to separate PRs. I am not enthusiastic with the EMPTY ACK mechanism, or with the proposed "implicit acknowledgement" of a lower crypto stream by a higher level ack. In any case, starting as simple as possible would help having the first implementations and tests.

Subodh

________________________________
From: QUIC <[email-masked]><mailto:[email-masked]> on behalf of Martin Thomson <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, May 22, 2018 8:00:40 PM
To: Ian Swett
Cc: [email-masked]<mailto:[email-masked]>; QUIC WG
Subject: Re: Stream0 Design Team Proposal

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 23 May 2018 22:37:09 +0000

FWIW I see EMPTY_ACKs as being very similar to a Duplicate ack. We thought about using Duplicate acks as well but we thought that EMPTY_ACks would be simpler to implement and be able to convey similar information.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Mike Bishop <[email-masked]>
Sent: Wednesday, May 23, 2018 3:26:35 PM
To: Christian Huitema; [email-masked]
Subject: RE: Stream0 Design Team Proposal

Christian, can you expand on why you dislike the EMPTY_ACK?  Being able to say “I’ve received some packets from you, but am unable to process any of them because I’m missing some handshake data” seems like a useful way to short-circuit timeouts on clients.  It also doesn’t commit the server to holding any state – IIUC, a server could form a packet containing an EMPTY_ACK and then discard its internal state until it gets the retransmitted (or delayed) Initial packet.

Subodh

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 May 2018 08:00:40 +0900

> The client can't send 1-RTT messages until it has sent Client Finished.  The server can send, but not process, 1-RTT messages prior to receiving Client Finished.  (This is a spec requirement rather…

That is true.

However, I think that the issue remains in case where 0-RTT is
involved. If the client sends it's request using a 0-RTT packet and
the server ACKs and sends a response in 0.5-RTT, there will be no
1-RTT packets from server after ClientFinished is delivered to the
server.

-- 
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 16:23:30 -0700

Just a point of order, because this thread can easily become a
thousand-tentacled monster.

There are many parts to the proposal. There was general agreement in the DT
that it's valuable to see all parts of what were discussed, even if some
parts stretched the original mandate, and even if some parts end up being
discarded. That is entirely the wg's prerogative. We should discuss
individual disagreements or points of concern, and I strongly recommend
forking off new threads for each of these points.

On Wed, May 23, 2018 at 3:23 PM, Mike Bishop <[email-masked]> wrote:

>    - Moving from Stream 0 to CRYPTO frames
>    - Removing the TLS record layer and using the TLS keys directly in
>    QUIC packet protection
>
> So I think that’s roughly six PRs we should expect to see out of the
> design team’s proposal.  A few of them have dependencies on each other, but
> they seem mostly separable.  It sounds like several of them have consensus
> in the design team, but not all of them, and it would be good to be able to
> discuss them separately.
>
>
>
> Right now, some of these appear to be entirely gratuitous.  I'd like to
> get to the bottom of each before we continue.
>
>
>
> right long-term direction and several TLS stacks (BoringSSL, PicoTLS, NSS,
> and
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 16:40:31 -0700

On Wed, May 23, 2018 at 3:23 PM, Mike Bishop <[email-masked]> wrote:

> discuss them separately

Hi Mike,

The vast majority of the proposal had consensus in the design team. It's
true that there are a few pieces that had somewhat less support and we just
made a decision in the interest of having a coherent proposal. These points
are called out explicitly in the Overview document.

With that said, I think it would be better to resist the urge to try to
decompose the proposal into its minimal constituent pieces. In many cases,
even when a piece is in theory independent from other pieces, there are
interactions and so we made a conscious decision to present it as a whole
proposal. Obviously, if there are explicit things that people object to,
they should raise them, but I think trying to break the proposal up into
pieces and consider them individually -- while intellectually interesting
--  isn't going to be that productive.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 May 2018 09:51:16 +1000

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.

helpful!

> 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

have
proposal
would
and

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 16:55:51 -0700

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 17:07:34 -0700

Fair enough. I think 0x18 is fine.

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

>> >> > working on implementations of this new approach, which we hope to
>> have
>> in
>> >> > be better to discuss those in the wider WG than delay the design
>> team.
>>   A

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 May 2018 07:39:20 -0700

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.