Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

"Salz, Rich" <rsalz@akamai.com> Wed, 02 December 2015 18:00 UTC

Return-Path: <rsalz@akamai.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 0BFDA1ACCF5 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 10:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 W1BbVIPE-wRR for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 10:00:28 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA51A8977 for <tls@ietf.org>; Wed, 2 Dec 2015 10:00:28 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2A24D16C091; Wed, 2 Dec 2015 18:00:28 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 140BC16BFA3; Wed, 2 Dec 2015 18:00:28 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449079228; bh=POOZAD+SDHqxSISp67G11m+csjGIsZWy/0gf6HYPtiU=; l=1001; h=From:To:CC:Date:References:In-Reply-To:From; b=v7+G2giYiBsHhVwj1JEEK5aP+xgKgp/gmw/dUqt2x5xVNtn1EVyBFWiHY6d5uKUIa 4pp4Y1zPgkJcUJI0UiaopW0Ug/JET3sbxZdndz9XrvdPS/FHg37vIKO/nBwF6hMyfm Qgw98T7BW99JumZ8Qc1LLYjO0ciSQaNUSPJeKBnE=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id EF3381E080; Wed, 2 Dec 2015 18:00:27 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Dec 2015 13:00:27 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 2 Dec 2015 13:00:27 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Jacob Appelbaum <jacob@appelbaum.net>, "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRKc4vwBJv/xDF6kerxoHYn7vyUZ6zDYQAgAEO5oCAAH2vgIAAG3yAgADwwYCAAAtCAIAAf4CAgAG7GgCAAAXqAIAAEJQAgAAK8QCAABr7AIAABrGAgAAIT4CAAB1aAP//rLHA
Date: Wed, 02 Dec 2015 18:00:26 +0000
Message-ID: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAFggDF3HP5u0YP0UP_HrrZnrTnzc-CD1EG0grZBcb5sB7A2fAA@mail.gmail.com> <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <CAFggDF0D3Rgav-4xg-11u0igMyMXvAWT+JNt2r1xyQnpvm08Qw@mail.gmail.com>
In-Reply-To: <CAFggDF0D3Rgav-4xg-11u0igMyMXvAWT+JNt2r1xyQnpvm08Qw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.38.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zpiI8VE7MKuk1YiZ8wEQ1VHo2PA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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: <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, 02 Dec 2015 18:00:31 -0000

> I think that is false. One could easily use the "cleartext" SNI field and insert an encrypted value. A hash of the name would be a simple example but not a secure example, of course.

Encrypted SNI doesn't give you the kind of protection you think that it does.  We (me and a colleague) did a pretty thorough analysis that showed this.  It was not a conclusion we expected, or wanted, to reach.   It was presented at the TLS Interim before the IETF in Toronto.  Slides should be online.  (For example, the adversary will know the IP address or might not care about false positives, etc.)

In spite of this, another colleague (Brian Sniffen) came up with a way to do it at the tail end of the Seattle interim.  Encrypt the "true" SNI in the semi-static DH key of a "fronting" site.  And then the front decrypts the true SNI and forwards to the obscured site. Ekr and dkg presented it in Yokohama, but not very well. :)  They're presumably working on something better.