[TLS] Does OE really belong in core TLS?

Erik Nygren <erik+ietf@nygren.org> Fri, 28 March 2014 16:31 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C17421A092F for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 09:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id moSDJL2_QqIw for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 09:31:29 -0700 (PDT)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D04441A00FB for <tls@ietf.org>; Fri, 28 Mar 2014 09:31:28 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id jz11so5838831veb.25 for <tls@ietf.org>; Fri, 28 Mar 2014 09:31:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=qcmeUsnfPnHzqyuYe0vgYu5vZka3A+s066T9C2PKQks=; b=Np67Ty6qaH8sces9CiEHw98EwbyN0GjfNOv5rqiLD4hoZOwmuqg6wY1mnSRd+IX7kx 18RJbqf4TEz/L/pdJB15Rs6HVfq0xfj0EUxP+pTsoqM7H65fzWM/UJEr3piTKQ0RZfxi lU8j7jojRflnz1RRSc9uCgkAolMEqKtFispA/8ZP0b+l2ffFk6D2zgYVAS2+M5yvwg5E 089rTIdSUiTrD5PxuffwsrddaiwesB2QvVBhjO8qOxi9xJXpcMwxhpuHglIN0R/T8MOU aps0OyLK/JqIxQHIbhIHlh72unDANE+ou97dTqvCVaH5omNeD9yygDzBbKZDOPctT4On jepA==
MIME-Version: 1.0
X-Received: by with SMTP id r7mr7971793vcm.11.1396024286471; Fri, 28 Mar 2014 09:31:26 -0700 (PDT)
Sender: nygren@gmail.com
Received: by with HTTP; Fri, 28 Mar 2014 09:31:26 -0700 (PDT)
Date: Fri, 28 Mar 2014 09:31:26 -0700
X-Google-Sender-Auth: ajwGlB8ln2m4xqBPqVjMQgxsy4s
Message-ID: <CAKC-DJih7g9Soyg+CA7haivPWPCfyMpoH18O_ZtGWRbmWLWVng@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b66f5fbb16bc104f5ad3b58"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d2xnWZbSiHhTRuMjhgacD5RAt54
Subject: [TLS] Does OE really belong in core TLS?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Mar 2014 16:31:31 -0000

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).