Subject: QUIC and security guarantees

From: Victor Vasiliev <[email-masked]>
Date: Mon, 23 Jan 2017 17:56:11 -0500

I've wanted to give my two cents on the TLS abstraction issue, but realized
that it would be useful to first provide decide where we would have to draw
the line if we draw it.  Because of that, I've tried to compile a list of
security guarantees and features we want the protocol to provide.  Please
tell me if I've missed something.

(1) QUIC should provide confidentiality and authentication to all of its
packets.

(2) QUIC should have an ability to securely establish keys for (1) in-band,
in a manner that at least works with TLS 1.3.

(3) QUIC server should not send more than a limited amount of data to the
peer until it has established that the peer can actually receive packets
addressed to it.

(4) QUIC should be able to support stateless rejects.

(5) QUIC should authenticate the transport parameters, notably the QUIC
version.

(6) QUIC should provide a mechanism to refresh shared keys post-handshake
(refresh for TLS tickets, source address tokens and traffic keys).

Packet protection solves (1), but I will note that its layering level in
the current documents is somewhat unclear: it lives in TLS binding
document, but the document makes it sound TLS-independent.  I think that
making the packet protection level fixed for all variations of QUIC
protocol is a reasonable plan.

We currently defer (4) and (5) to TLS, and I will note that (3), the issue
we currently solve with source address tokens (STKs), has interesting
interactions with stateless rejects.  We currently don't have a solid
stateless reject mechanism spelled out in the documents, and I expect them
to have a lot of subtle interactions with proof of source address (a
notable edge case here is when the server cannot send the entire
certificate in one flight because it's so big it becomes an amplification
concern).

Because of that, I suggest that we postpone the discussion of whether to
put source address tokens into TLS layer until we have a plan for stateless
rejects thought through.  I've been having conversations with people about
how one should work, and will be happy to present a mechanism with edge
case analysis by the March meeting.

  -- Victor.