IETF Logo Mail Archive

Re: [TLS] DNS-based Encrypted SNI

"Sniffen, Brian" <bsniffen@akamai.com> Tue, 03 July 2018 14:26 UTC

Return-Path: <bsniffen@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD090130E04 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 07:26:16 -0700 (PDT)
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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 tF-N9wAMG2Ls for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 07:26:13 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE04E130DE6 for <tls@ietf.org>; Tue, 3 Jul 2018 07:26:13 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w63EMHel026643; Tue, 3 Jul 2018 15:26:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=fcBNIAqHYuzrq34ypkn1Qplpb4jc7lmfuGuK1q5fzUo=; b=h1x8Y5530fthXRQ7Zayfm738KAtUjDlZqJpim3KLe9eXwbasGMfMUNGOTEbWGYEpElX6 k1IQTJoDEtyRpuX/cMrP2UWso6i6jYPluV1dvYnUnkwvM25MVXgQw9E0o//1/dZtqOXu hZDdmwQ9HHLs98qvxIJ/2NLB50E3pupdgjMSzTKIdGpGZEHw/qyQHr9dvT205d1HBkv5 frECecf0L5P/ZmftcDJK6st3peoHcgGCuENM4lW/eHwCwNRnRZxWOX4/W9z+8XI4XMC5 oyJ/Zr/Apd9mbjf+6FC1YFUQrQfKqSM9E5ktBk1TY6Dsd2r+143jHSsGox40mXJpuhsY pw==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2jx1ju9033-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 15:26:13 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w63EJeGa001489; Tue, 3 Jul 2018 10:26:11 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jx57ba5wh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 10:26:11 -0400
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 3 Jul 2018 09:26:10 -0500
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Tue, 3 Jul 2018 07:26:10 -0700
From: "Sniffen, Brian" <bsniffen@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] DNS-based Encrypted SNI
Thread-Index: AQHUEl5BGfRrHHIWEE6kZ2BXRr3upKR9jtZq
Date: Tue, 03 Jul 2018 14:26:10 +0000
Message-ID: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com>
In-Reply-To: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030165
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030166
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-ThiN9P53UoV5jw_i1NfmrVt05A>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 14:26:17 -0000

Looks neat. 

1) TFO DOS vector: is the idea servers will disable TFO under strain but not be able to disable ESNI?

2) “clients might opt to attempt captive portal detection to see if they are in the presence of a MITM proxy, and if so disable ESNI.”

If I’m operating a great firewall, I can use this to discover dissidents, right?  Either they send me dangerous SNI values or they are configured to not disable ESNI, and taking the fifth is fatal. To protect them, I think nobody can have this mode. 

3) How many bits does this offer? Hiding in a set of a million uniform hosts is 20 bits, and the nonuniformity will accrue to the adversary’s benefit. Active probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the purpose of allowing dissident access to restricted web sites that it will be dangerous if released. But maybe I misunderstand the purpose. If this is just to keep Western ISPs from monkeying with traffic, sure, ship it.  Labelling the encryption with its strength as applied, or showing CDNs and ISPs how to work out some bounds, seems one way to help users understand whether this can help them or put them more at risk. 

-- 
Brian Sniffen

v2.23.0 | Report a Bug | By Email