IETF Logo Mail Archive

Re: [TLS] ESNI and Multi-CDN

"Salz, Rich" <rsalz@akamai.com> Tue, 18 December 2018 19:56 UTC

Return-Path: <rsalz@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 301CB130F29 for <tls@ietfa.amsl.com>; Tue, 18 Dec 2018 11:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level:
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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] 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 nNF0gnlu9XKQ for <tls@ietfa.amsl.com>; Tue, 18 Dec 2018 11:56:34 -0800 (PST)
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 B519B130F28 for <tls@ietf.org>; Tue, 18 Dec 2018 11:56:34 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wBIJqrFT028033; Tue, 18 Dec 2018 19:56:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hnK75vZPsoSlPFv9+z9m88CUJlw5HseSH4adDFyE52M=; b=c1rnQPQdKy78hvLgIz14hABVTjEG86yionJa67+DJ4g0cZfpj/asYfE2loQ3VlwBiJaP +MvE7h+8oPCPoqWy3pb8wFeXxH9brNIUUHh4oto218/ccMSdsBIFoUqE1WiBcK6eFhOx wFd5IT0J7RR+YO07oF32K3h6MTbit7OC+jy9QINM3WRf1RDFZx5bIkXKxtfOSHz4Sb2h hXDlGnirIFQHrKDxbDBARaDzDlGJw2QlvXo/IfeQ/IZq1voSsc+MV1XE16IhU/i/0ICW gUtq17OKiXPggX1B/D9XZZcU2ad+m79HHKVFfCf2CJdIKxUeaCvPpE6/91J3A5WmRa2B aQ==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2pephp33s7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Dec 2018 19:56:29 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wBIJo3Fx004263; Tue, 18 Dec 2018 14:56:28 -0500
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2pcwu09x5n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Dec 2018 14:56:22 -0500
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; Tue, 18 Dec 2018 13:56:03 -0600
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; Tue, 18 Dec 2018 13:56:03 -0600
From: "Salz, Rich" <rsalz@akamai.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ESNI and Multi-CDN
Thread-Index: AQHUlvdfzmyswisZZkmK1IQ9jYCvlqWE+j2A
Date: Tue, 18 Dec 2018 19:56:03 +0000
Message-ID: <2A545CCE-4453-4FFB-86B6-233A28B79534@akamai.com>
References: <CAHbrMsCDR4oQzJhkcF05+wSKEoDEnACLH8D-os34xoNE9hyWHQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCDR4oQzJhkcF05+wSKEoDEnACLH8D-os34xoNE9hyWHQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.14.0.181208
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.209]
Content-Type: multipart/alternative; boundary="_000_2A545CCE44534FFB86B6233A28B79534akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-18_08:, , 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-1810050000 definitions=main-1812180163
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-18_08:, , 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-1810050000 definitions=main-1812180164
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/n0XXVdLFYDJioRV7tNCmt6eLgA0>
Subject: Re: [TLS] ESNI and Multi-CDN
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Dec 2018 19:56:36 -0000

  *   I'd like to propose a solution to the ESNI + Multi-CDN problem (which has been discussed a lot on this list already).  My suggestion is that we define the ESNI DNS record format as optionally including "stapled" A/AAAA records.

As in a multiple response?  That might be interesting, but it allows an adversary to just strip those responses, right?

> This kind of address stapling would only be required of CDN operators who want to support multi-CDN deployments.

Or anyone who maintains DNS records for a site that wants multi-CDN.  Many of our customers, for example, maintain their own DNS.  It’d say its common because they want switch quickly (very short TTL).  Yes, this usually is okay because the initial redirection is done via CNAME, but it is worth calling out that explicitly.

                /r$

v2.23.0 | Report a Bug | By Email