Subject: [QUIC] Comments on draft-thomson-quic-tls-<latest>

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 06:28:37 +0900

Thanks for doing this document. I think it's looking pretty good.

You and I talked offline about changing the key update pattern a bit,
so I omit those comments here.

I notice that this document does not cover stateless reject (and
draft-hamilton is a bit vague too). That seems like something that
wouldbe good to address.

SUBSTANTIVE
S 4.4.
It's kind of gross to tie key updates to ACKs as you do here. As I
understand it, if you make the changes we discussed F2F to the
key update schedule, you can remove this restriction.

S 5.1.3.
I would suggest just never sending ACKs with 0-RTT keys. That would
make life a lot simpler.

One point that you may need to address here is what key the server
uses for acks of CH. Consider the case where the CH is one packet
but SH..SFin are several. The keys you need to decrypt the ACKs
cannot be computed until you have SFIN. I think the right answer
may be to actually make a stricter requirement than the one you do:

- ACKs for unprotected data other than ACKs, which IIRC are ACKed
  are unprotected
- ACKs for protected data are protected.

EDITORIAL
I don't think the reductions of HKDF-Expand to HMAC in 4.2.2 are helpful.
People should just call HKDF-Expand. It's not like they don't have
a TLS stack.

---

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 15 Nov 2016 00:01:18 +0100

> - ACKs for protected data are protected.
In my opinion data encrypted with 0-RTT keys needs to be acked in cleartext
that is needed to ensure prompt retransmits. The server can start
encrypting acks when it receives the client  finish message or a packet
that is encrypted with 1-RTT keys.

 dragana

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 08:14:07 +0900

On Tue, Nov 15, 2016 at 8:01 AM, Dragana Damjanovic <
[email-masked]> wrote:

> In my opinion data encrypted with 0-RTT keys needs to be acked in
> cleartext that is needed to ensure prompt retransmits. The server can start

Maybe. This is only really an issue when;

(a) some 0-RTT data is lost (otherwise you don't need it)
(b) pieces of the server's first flight (SH...SFIN) are lost and therefore
the client can't compute the server's 1-RTT keys.

At this point it seems like it's not exactly a crisis if you don't get
super-prompt retransmission of the 0-RTT data.

-Ekr