Subject: [QUIC] TLS in QUIC problems

From: Watson Ladd <[email-masked]>
Date: Tue, 26 Jul 2016 18:51:20 -0700

Dear all,
As we all know, formats write their own exploits. The more complicated
a parsing operation is, the easier it is to screw up, and the more it
is screwed up, the more exploits. TLS has a rather complicated format
combining fixed length and length prefixed fields with several layers
of nesting, and the result is all kinds of latent bugs in
implementations that harm extensibility as well as security.

QUIC very carefully chose to use a uniform TLV format, with only one
layer of nesting permitted. The result is that this is easy to
completely parse into a structure that contains all the relevant
information, and ignoring unused fields is easy. TLS implementations
don't do this, instead resorting to shotgun parsing with consequent
catastrophe.

The proposals I've seen to use the TLS handshake in QUIC abandon this.
What do we gain vs. having a sane reencoding of the data structures
used in the TLS handshake?

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jul 2016 20:30:23 +0300

> On 27 Jul 2016, at 4:51 AM, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,

Code re-use. If OpenSSL, BoringSSL and a few others get it right, your QUIC implementation can just use that.

If these libraries have horrible security bugs, we’re screwed anyway because we use them for old-fashioned HTTPS.

Yoav

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Jul 2016 17:49:22 +0000

On Wednesday, July 27, 2016 10:30 AM, Yoav Nir wrote:
> > ...

Not just code reuse, but also attack surface reduction. In all realistic scenarios, browsers and servers will support both HTTPS and QUIC. If we have two different security stacks, we have to be worried about the combined surface of both stacks.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Thu, 28 Jul 2016 20:16:24 -0700

> Not just code reuse, but also attack surface reduction. In all realistic scenarios, browsers and servers will support both HTTPS and QUIC. If we have two different security stacks, we have to be wo…

This cost applies to any new transport layer or any other protocol,
yet we still pay it. Even granting the facts under your argument,
it would say that we must never introduce simple security protocols,
as the more complex ones will still be around and the new alternatives
will therefore increase the attack surface. This is clearly
antithetical to any improvement in the situation.

Of course, the facts underlying your comment are wrong. Lots of
devices beyond browsers and servers use TLS. In many cases both ends
of a communication are under control of a single entity, making
switching protocols easier.

Your QUIC implementation cannot just use OpenSSL. OpenSSL wants to
drive the IO on the sockets handed to it, and expects TLS records to
come in, not TLS handshake records. Of course there are dirty hacks
around it. Or perhaps you don't have the resources to use OpenSSL,
have licensing problems that make distributing it with your software
hard, or don't feel like 0.9.8.zz is the pinacle of software
correctness.

Simplicity and ease of implementation are virtues.

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