[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.220.92.135 with SMTP id r7mr7971793vcm.11.1396024286471; Fri, 28 Mar 2014 09:31:26 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.221.18.70 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). Erik
- [TLS] Does OE really belong in core TLS? Erik Nygren