Subject: Performance/safety trade-off

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 17:29:01 +1100

In PR #39, there is a choice:

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

If a server receives 1-RTT-protected packets before it receives the
client Finished message, it could use them.  It has the keys.

Obviously, if the server depends on certificate-based client
authentication it will wait.  But that's still a relatively rare
occurrence.

However, using 1-RTT data before verifying the Finished message could
leave the server more vulnerable to an attack where the ClientHello is
modified by an attacker.  This is something that TLS 1.3 protects
against, but only indirectly.  The traffic keys are dependent on the
content of the ClientHello and so it is likely that modifications of
the ClientHello would result in being unable to communicate.  But this
isn't a strong assertion.  The various forms of analysis of the TLS
1.3 handshake have all (I think) assumed that verification of the
Finished message is what provides integrity for the handshake.

In #39, I opted to forbid use of the client 1-RTT data until the
handshake completes.  I'd like to confirm that this is acceptable.

In addition to confirming this, I'd like input on what level of
justification is necessary for this in the document.  If we believe
that this is the right decision, do we need to do anything to prevent
someone from pulling out a false start hack because they disagree with
this analysis?

---

From: Ian Swett <[email-masked]>
Date: Tue, 31 Jan 2017 11:22:41 -0500

My intuition is that forbidding the server from processing 1RTT packets
until the client finished message is received would be a very small impact
on latency if it was just a matter of waiting for the re-transmission.
However, if the server can't process those packets, it can't send an ack
for them, and the ack would indicate the client finished message had been
lost, which would speed up loss detection.

So it seems like a bummer to not be able to process them.  This would also
mean the server couldn't process an ack for any 1RTT data the it sent,
since that would be encrypted.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 31 Jan 2017 08:27:02 -0800

> Finished message is what provides integrity for the handshake.

I don't believe the finished message is necessary for ensuring
manipulation of the client hello message is detected.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 31 Jan 2017 09:17:20 -0800

Since the keys cannot be the same if the ClientHello were to be modified,
what is the risk we are talking about here? I don't know about the crypto
analyses of the TLS handshake, so some insight here would be helpful. But I
agree that having the server process 1-RTT data would help with loss
detection. If there's no real security implication, I'd be in favor of
letting the server process this data.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Feb 2017 10:08:05 +1100

> manipulation of the client hello message is detected.

Nor do I.  That's not the same as saying that it's perfectly safe to ignore it.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Feb 2017 10:23:04 +1100

The security analyses of TLS assume receipt and verification of the
Finished message.  It's an obvious intuition that keys depend on the
content of the message, therefore tampering would be easily detected.

That said, we've learned that intuition is often wrong in this space,
sometimes disastrously.  We don't have an analysis of TLS that ignores
the client Finished message.  So unless and until we do, I don't want
to write down anything that isn't known to be safe.

I know that this sucks in subtle ways, particularly in the way that
Ian observed with respect to acknowledgments.  Because we require that
the Finished is acknowledged with protected keys, we lose the ability
to generate acknowledgments for them.

I see three possible approaches:

1. As I originally suggested, suck it up and don't let the server send.

2. Don't protect the Finished (it's protected with TLS handshake keys
anyway).  That would allow for acknowledgment in the clear.  That
requires a tweak to the way that keys are shared, but it's a fairly
simple tweak.  The major downside is that we now have an extra packet
to send, because you can't collapse the Finished message with other
things (like requests).

3. In the hackiest possible way, generate a redundant ACK for the
ClientHello in the clear.  If that could trigger retransmission of the
first encrypted packet(s), then we'd be OK.  (Sorry, I haven't
internalized the loss recovery stuff, so I'm not sure if this even
works, we could be back into RTO space here.)

Maybe option 2 is more appealing than appalling.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 31 Jan 2017 15:36:36 -0800

On Jan 31, 2017 3:23 PM, "Martin Thomson" <[email-masked]> wrote:

I think someone who is more experienced/familiar with the analysis should
chime in. My understanding is that the ROM quickly gives high probability
of the keys being different and hence the MAC failing, and the Finished
message is there to give an explicit confirmation property.