[TLS] Comments on draft-ietf-tls-sni-encryption-01.txt

R du Toit <r@nerd.ninja> Wed, 21 February 2018 23:31 UTC

Return-Path: <r@nerd.ninja>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 873DE1277BB for <tls@ietfa.amsl.com>; Wed, 21 Feb 2018 15:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FwEhUCPOW4wk for <tls@ietfa.amsl.com>; Wed, 21 Feb 2018 15:31:51 -0800 (PST)
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0313F126C3D for <tls@ietf.org>; Wed, 21 Feb 2018 15:31:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1519255905; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=10701; bh=ih9bOBfGXM6uZnZTs2I3LMsUVh8mH/Pcd940pYd5qPk=; b=nL5c6sNBVMSdBWXz7KPwiwEpi0B2h0fneNRe+4Zmqpc9SBS2g+jJKk++MV5lV+0O DV3OSATkjmI3A7Vt3U3WGRuMHIV8xORt6hY2Y8aXBFCsBqDdihcWqFtUEHXCvNqtgLe hB8ZLMeRQYe1eQ6Bb7rpAUNWxZkLk8B0quGK7wVY=
Received: from [] (dynamic-acs-24-112-242-116.zoominternet.net []) by mx.zohomail.com with SMTPS id 1519255905151499.2341976568034; Wed, 21 Feb 2018 15:31:45 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Wed, 21 Feb 2018 18:31:42 -0500
From: R du Toit <r@nerd.ninja>
To: Christian Huitema <huitema@huitema.net>, "tls@ietf.=?UTF-8?B?b3JnwqA=?=" <tls@ietf.org>
Message-ID: <9C911514-298C-48EB-BF2E-E7AEDF6411F6@nerd.ninja>
Thread-Topic: Comments on draft-ietf-tls-sni-encryption-01.txt
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3602082704_289157534"
X-ZohoMailClient: External
X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/21GGK2GYoQykiwdAcA-GuM8KK2I>
Subject: [TLS] Comments on draft-ietf-tls-sni-encryption-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 21 Feb 2018 23:31:52 -0000

I have analyzed the two mechanisms proposed in the draft, with specific focus on the impact of middleboxes. 



The middlebox is deployed inline, between the client and the fronting server, and is allowed to intercept TLS sessions.  The middlebox is policy-driven, and uses SNI as an input in determining whether or not to intercept the session; the policy must use the SNI of the hidden server.


Mechanism #1 : Tunnel ClientHello in 0-RTT early data.

(1) Mechanism #1 requires 0-RTT support, but the middlebox would not be violating the TLS 1.3 specification by not implementing 0-RTT.  The middlebox intercepts all sessions destined to a specific fronting server (F); the identity of F should be public knowledge, but even if it is not, we have to assume that the middlebox has a mechanism to decide when to intercept sessions destined to F.  


(2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS intercept with PSK/0-RTT support in the session between the client and the middlebox, as well as PSK/0-RTT support in the session between the middlebox and the fronting server.  The middlebox will be able to decode ClientHello#2 sent in the 0-RTT early data because the client_early_traffic_secret will be known to the middlebox.  The middlebox would thus have access to the SNI of the hidden server, and would be able to evaluate policy.  The middlebox would have the option to pull out of the session after sending ClientHello#2 to the fronting server (re-encrypted with the client_early_traffic_secret shared between the middlebox and the fronting server).


Mechanism #2: Session ticket that can be decoded by Fronting and Hidden server.

(3) Mechanism #2 relies on PSK session resumption support in the middlebox; this is not guaranteed.


(4) The middlebox would not participate or interfere in any of the out-of-band channels between the fronting server and the hidden server, which implies that the middlebox will not be able to decode the session ticket generated by the hidden server - but it does not have to.  The middlebox would be able to observe the encoded session ticket in the NewSessionTicket message because it intercepts the initial TLS session between the client and the hidden server (even if mechanism #1 is used for the first session).  The middlebox would thus be able to extract the SNI of the hidden server from the NewSessionTicket message and build a mapping of encoded session tickets to hidden servers. TLS sessions (destined to the fronting server) that were not previously intercepted by the middlebox will use PSK identities that are not in the mapping table - the middlebox would likely force intercept of those sessions and strip the unknown PSK identities, which would result in a TLS session that terminates on the fronting server, leaving the fronting server without any knowledge of the hidden server.


(5) Ignoring middleboxes, in my opinion the infrastructure required for collaboration between fronting servers and hidden servers (stateful, shared-key, public-key, or otherwise) would be a practical barrier to entry for most server administrators.