Subject: [QUIC] Comment on draft-thomson-quic-tls-01

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 2 Nov 2016 19:10:32 +0100

Hi,

I had a quick look at draft-thomson-quic-tls-01. My apologies if I miss
something.

During a handshake a client can received messages form a serve in clear
text, protected by 0-RTT key and 1-RTT key. There is only one bit to
distinguish which of the 2 keys or clear text  is used. This will need more
explanation, e.g. how to distinguish a clear text server hello and messages
protected with 1-RTT key, as well as a a server hello protected with 0-RTT
key and messages protected with 1-RTT key. This 2 combination can be
confused if some of packets get lost.
Maybe this is left for the next update of the draft (in that case sorry for
the noise).

dragana

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Nov 2016 12:20:41 +1100

> Maybe this is left for the next update of the draft (in that case sorry for

The fact that the current version allows the server to encipher with
the 0-RTT key is a bug.  That violates the security guarantees TLS
provides regarding key use (it's a subtle thing, but it's down to the
way the formal analysis of TLS has been performed).  I neglected to
merge the PR that talks about this before submitting, but my copy here
is up to date: https://martinthomson.github.io/quic-tls/

Generally speaking, there are only two different keys in use for any
given direction at any one time.  This includes cleartext vs. 1-RTT.
The epoch bit helps to identify which of those is in play.  I intend
to do a bit of an overhaul of this stuff, since it's the most
complicated and confusing part of the draft.  It's also the kludgiest
because it requires integration with packet acknowledgment.

The trickiest part is that TLS cleartext handshake packets need to be
retransmitted using the cleartext epoch (or the 0-RTT epoch for the
client's second flight if 0-RTT was accepted), even if you have 1-RTT
keys.  This means that you can't move to the next epoch until you are
certain that you don't need to retransmit any handshake packets.  The
only good part is that as far as QUIC is concerned handshake packets
are always cleartext or 0-RTT and you always know which.

---

From: Dragana Damjanovic <[email-masked]>
Date: Thu, 3 Nov 2016 15:14:37 +0100

Sorry I have not looked at you repo, I was just reading the last 01 draft.

With the new version the problem is resolved. The transition from 0-RTT to
1-RTT still needs to be fixed. The draft says it will switch to 1-RTT after
sending finish message, but it can't. That is what you are saying in this
e-mail? It needs to continue using 0-RTT until client finish message is
acked.

dragana

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Nov 2016 11:46:02 +1100

> Sorry I have not looked at you repo, I was just reading the last 01 draft.

Don't apologize, it's my fault :)

> e-mail? It needs to continue using 0-RTT until client finish message is

I don't think that's necessary.  In the latest TLS 1.3, the 1-RTT keys
only depend on the transcript up to the Server's Finished.  That means
that the server has enough information to decrypt the 1-RTT keys as
soon as it has finished sending its handshake messages.  Therefore, if
the client can switch to 1-RTT, it should do so as quickly as
possible.  (This is a change since I wrote the draft, so the draft is
probably wrong.)

The challenge I'm talking about is that the client's Finished (and
Certificate{|Verify}) need to be sent in the clear (or 0-RTT).  Until
they are acknowledged, the client can't rotate keys.  If the client
doesn't use 0-RTT, those packets will have KEY_PHASE=0, 1-RTT packets
will have KEY_PHASE=1, and any updated key will result in packets with
KEY_PHASE=0.  Those updated packets appear to be the same as the
"cleartext" handshake packets.

Normal key updates are easier because you only have to look for an ack
of any packet with the new KEY_PHASE.  The handshake is terrible
because you can get an ack of the first 1-RTT data, but the server
might not have finished receiving handshake messages.)

---

From: Dragana Damjanovic <[email-masked]>
Date: Fri, 4 Nov 2016 10:02:16 +0100

> "cleartext" handshake packets.
I think we are talking about the same thing. I was only saying that problem
exist if 0-RTT key is used. After the client has sent Finish message it
knows 1-RTT key but it can't rotate keys and  it can't start sending
messages using 1-RTT key, because server can get confuse whether it is
clear text or 1-RTT key-encrypted message. It needs to wait for the ack of
the Finish messages. This is too long to wait, it is one RTT if nothing
gets lost.
I was suggesting to continue sending data using 0-RTT until ack arrives.

dragana

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 4 Nov 2016 21:14:59 -0700

On Friday, November 4, 2016 2:02 AM, Dragana Damjanovic wrote:
> On Fri, Nov 4, 2016 at 1:46 AM, Martin Thomson <mailto:[email-masked]> wrote:
> Don't apologize, it's my fault :)

Well, I am looking at the version on Martin's repo, and there are a few things that I don't get.

The flow diagram in 2.1. Handshake Overview supposedly mimics the diagram in section 2.3. Zero-RTT Data of the TLS 1.3 spec, except there is a minor difference, probably an oversight, the "(Finished)" message after the Hello and extensions. There is no such message in the TLS 1.3 diagram, although there might have been in a prior version. The other difference is the timing of early data. 

The text in the introduction of section 3 says that "QUIC Stream 1 carries a complete TLS connection. This includes the TLS record layer in its entirety." That means that we have two potential layers of encryption: the QUIC record protection, which is protected by the keys described as @A, @B, @C in the diagram; and the TLS record layer, which protects some of the messages sent on stream 1. @A is clear text. The draft says that "The server sends its handshake messages without protection (@A)". That's true as far as the QUIC record layer is concerned, not so true for the TLS layer itself.

In the same vein, I would like to understand why the last flight of TLS client messages (end of early data, finished) are protected by the 0-RTT key (@B) rather than the 1-RTT key (@C). Isn't end-of-early-data triggering a transition to @B? In fact, why are we concerned with early data on stream 1? If the client sends early data, it will be probably using stream 3, and the TLS record layer will not be engaged.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Nov 2016 14:31:36 +1100

> The flow diagram in 2.1. Handshake Overview supposedly mimics the diagram in section 2.3. Zero-RTT Data of the TLS 1.3 spec, except there is a minor difference, probably an oversight, the "(Finishe…

I've removed this from my version.  It disappeared in a recent version
of TLS and I didn't track well enough.

> The text in the introduction of section 3 says that "QUIC Stream 1 carries a complete TLS connection. This includes the TLS record layer in its entirety." That means that we have two potential laye…

Yes, this was the result of a lot of back-and-forth.  The advantage is
that it avoids shifting the complexity associated with handshake
encryption to QUIC.  It also keeps the implementation pretty simple,
because we can use TLS (not DTLS).

The disadvantage is that you double-encrypt a few packets.  Right now,
those packets are the NewSessionTicket, the client's final flight, and
maybe the close_notify alert.  I can't think of any other data that
TLS encrypts that needs to be sent right now.

> In the same vein, I would like to understand why the last flight of TLS client messages (end of early data, finished) are protected by the 0-RTT key (@B) rather than the 1-RTT key (@C). Isn't end-o…

The finished was a mistake.  However, I've no good concept of what to
do with end_of_early_data.  QUIC probably doesn't need it at all,
since it marks transitions between 0-RTT and 1-RTT with the KEY_PHASE
bit.  As you observe, sending it on stream 1 isn't going to have the
desired effect.  I've opened
https://github.com/martinthomson/quic-tls/issues/12 to track that.