Subject: [TLS] Does OE really belong in core TLS?

From: Erik Nygren <[email-masked]>
Date: Fri, 28 Mar 2014 09:31:26 -0700

I was thinking more about one of the post-meeting discussions on the
proposed new flows and SNI (and handshake) encryption.  One question that
jumped to mind is whether or not it is prudent to build features into the
core of TLS 1.3 that are vulnerable to active attacks?

In particular, if the only way of encrypting the handshake is effectively
opportunistic encryption, is it better to not do this at the TLS layer?
Having parts of TLS be vulnerable to active attackers seems like it has the
potential to make TLS much harder to reason about, especially for
implementers and for people trying to understand what security properties
it provides (beyond magic security pixie dust).

It feels like OE may only belong in layers above or below TLS.  At layers
below (eg, via tcpcrypt or ipsec), it may be easier to set expectations for
using OE in ways that would protect the TLS handshake but without making
the properties provided by TLS itself harder to reason about.  (On the
down-side, this may be harder to implement due to adding extra round-trips
and due to the potential for additionally encrypting traffic on yet another
layer.)  On the layers above TLS (eg, HTTP), it may be easier for
applications to reason about the consequences of OE (such as by enforcing
an "http" scheme with no visible user behavior change in the cases where no
endpoint authentication is performed).

At a very minimum, we need to make sure that if there is any OE as part of
the TLS 1.3 handshake that there's a very clear distinction between the
opportunistic part ends and the where the actual authenticated part begins,
with a clear distinction of what is within each and how they are securely
glued together (if such is possible).  For example, sending actual data
during the OE part before the authentication completes seems very dangerous
and hard to reason about.

I realize that encrypting more of the handshake is a charter item for TLS
1.3, and that there's a general desire to protect against passive
monitoring, but it may be worth carefully considering the consequences of
adding features to the core of the TLS protocol that are vulnerable
by-design to active attacks (rather than addressing this at other layers).

        Erik