Subject: [quicwg/base-drafts] Protected pre-handshake packets (#39)

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Nov 2016 22:41:55 -0800

It's servers that will have to work this out, the client is simply unable to decrypt in this case.  The tricky part is on the server, where it has to work out whether it can use a 1-RTT protected packet, even though it hasn't seen the client's Finished.

Obviously, if there is client authentication, wait.  That's easy.

I've allowed a server to use these packets if it accepted 0-RTT on the basis that the 1-RTT keys are strictly better than the 0-RTT keys and that it wants to continue processing data.  I've said that it has to assume 0-RTT protection, even though technically these aren't subject to replay.

I've weaselled out of saying anything about the third case (no 0-RTT).

@ekr, thoughts?
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/39

-- Commit Summary --

  * Protected packets prior to handshake completion
  * Fixup a few gaffes
  * Reflow

-- File Changes --

    M draft-ietf-quic-tls.md (40)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/39.patch
https://github.com/quicwg/base-drafts/pull/39.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/39

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Nov 2016 22:42:18 -0800

Oops, thoughts on list if you can please.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/39#issuecomment-263194847