Re: [TLS] DNS-based Encrypted SNI

"Short, Todd" <tshort@akamai.com> Fri, 06 July 2018 20:22 UTC

Return-Path: <tshort@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 31F1D130F17 for <tls@ietfa.amsl.com>; Fri, 6 Jul 2018 13:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HgZ6kthe92_V for <tls@ietfa.amsl.com>; Fri, 6 Jul 2018 13:22:07 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 6FAC3130F0E for <tls@ietf.org>; Fri, 6 Jul 2018 13:22:07 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w66KLfGa015410; Fri, 6 Jul 2018 21:22:05 +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 : mime-version; s=jan2016.eng; bh=RBqp3uWeFXeZuyxPsabS12bPAkbwCFYD3DGC6Cl5+WE=; b=nuEH9Qfmo9HVjxMFs9KQN8Qt1Mg6XcpElFN0bkix1l9lnhG7G7Nkl/7Jff6WOMJe/xEd nGZj8BoZ5qtBYGQN0tZ/eoIDu2HzInCTk2QcXexBclkDhIH+gaOvN+cefn6zjCIrDJBR tonirP8nZ3IveUkqqOhq49tXJnoOCEjnWCSA8+uFW+TVW8Kq1fkGI4HRE0maSf8RBlLg bEwgQjHyVXX0SLW4YfJXuBj9E+/nJSg/RVngXJythSsJg6+EBIRf6iPHAP+fcBSkFpaI LpYGhfMhz3rW62F3KRYokfuh1LsK5SFOtMD0Kx8u8rOliq8XVJOYi6TBWAKTZICSvNQB ng==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2k0vct0w99-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 21:22:05 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w66Jo0dm012205; Fri, 6 Jul 2018 15:55:15 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jx57b1tc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 15:55:14 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 6 Jul 2018 14:55:12 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 6 Jul 2018 14:55:12 -0500
From: "Short, Todd" <tshort@akamai.com>
To: "<tls@ietf.org>" <tls@ietf.org>
CC: Eric Rescorla <ekr@rtfm.com>, "Sniffen, Brian" <bsniffen=40akamai.com@dmarc.ietf.org>
Thread-Topic: [TLS] DNS-based Encrypted SNI
Thread-Index: AQHUEl5BbRY0wnPzbU+tvvqDIqSVJKR94qgAgAUS64A=
Date: Fri, 6 Jul 2018 19:55:12 +0000
Message-ID: <B266359D-2187-42F5-AFB5-5E55D9D060E7@akamai.com>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com>
In-Reply-To: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.145]
Content-Type: multipart/alternative; boundary="_000_B266359D218742F5AFB55E55D9D060E7akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , 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-1807060222
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , 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-1807060229
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/n-7hfcfqfn2bk7pHwgDAmr635yg>
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: Fri, 06 Jul 2018 20:22:09 -0000

Fundamentally, unless this type of protection is baked into the protocol from the beginning, and is not an add-on option, any one/thing in the path can prevent the use of optional security features.

Don’t want people to access site XYZ? Block DNSSEC, block _ESNI DNS requests/responses, block the use of ESNI, etc.

A firewall can also use the record_digest to determine the destination, without even decrypting the ESNI. It just calculates the possible record_digests of the blocked sites; since the information is public. This will make it appear that ESNI is supported (for legal sites), but still block the use to illegal sites.

Or even do a reverse-DNS lookup on the destination IP, discover all the domains there, and then calculate the possible record_digests to see where the user is going.

This could be mitigated by having the same ESNIKeys for different websites, but that means the "Split Mode Topology" is broken as the record_digest cannot be used by the Client-Facing Server to select a Backend Server. Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, then doesn’t matter. This is not the case, as the IP address can now be used along with the ESNIKeys to know what the final destination is.

--
-Todd Short
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=40akamai.com@dmarc.ietf.org<mailto:bsniffen=40akamai.com@dmarc.ietf.org>> wrote:

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

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls