IETF Logo Mail Archive

Re: [TLS] ESNIKeys over complex

"Salz, Rich" <rsalz@akamai.com> Wed, 21 November 2018 03:40 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 DC902130E63 for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 19:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level:
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 rKq8Mb6JFn7o for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 19:40:14 -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 E4BC3130E5B for <tls@ietf.org>; Tue, 20 Nov 2018 19:40:13 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wAL3bW6p018460; Wed, 21 Nov 2018 03:40:09 GMT
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=ebkUAbrYGMpLG7LdQLR//BH37CYuSewzaDBPPH5p8x8=; b=i0V6ff2Ac79sYJoskLJbT6zc47ljERp/UV8GMx6leCiNkK7Um+Wz2cocNQZgS/He24nc PIVvbO04r2plCeJ9SHbhwbISeqCc8l0tcTCpb6Idno3URxNcA3NB+GC6IEXn5jXAvYZW ayGxzdaJdFlBhh4mXJA28B8wfZH/jXZVMy8iL+wa62QjuzQ8f/SAG4WCZLdbRAdqPvyB RzzYFGz6Ix/6ihxshC4aO+r8frRaTW0sR7S+ATr72BiOZ35IQRlGjo9NAHZ6DFh8B/Wg cGIWWYEl4sgDZC2cC1mKELg3t08E1ADOjrO4Zy6EFVgb+aFVj8KvtVw6i3xQ9zMuYS6+ 8g==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2nvtyk8tks-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Nov 2018 03:40:09 +0000
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 wAL3Z7Ri023675; Tue, 20 Nov 2018 22:40:08 -0500
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ntf7grq18-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Nov 2018 22:39:57 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 20 Nov 2018 21:37:56 -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, 20 Nov 2018 21:37:56 -0600
From: "Salz, Rich" <rsalz@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ESNIKeys over complex
Thread-Index: AQHUgRp4jEI7fT0zIkuqNBgjOdSti6VZtIWAgAASZYCAAAZgAIAAB8aA//+2egCAAFxZAP//vdcA
Date: Wed, 21 Nov 2018 03:37:55 +0000
Message-ID: <1E8AA9CB-3BCE-45EF-A454-74D547E80397@akamai.com>
References: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie> <CABcZeBMNqkepLzdoPFV7UTuKUqPU6_AJjU7iMnUhDpdK6qr6RA@mail.gmail.com> <70290643-cf98-44de-ca6e-2cae4584d750@cs.tcd.ie> <CABcZeBOp+auFAwc7_+DjEy0JJbvqzs-1Z30h-tFveesm9gwHEg@mail.gmail.com> <8546c227-a5e1-e17b-edce-ca173c8cfa81@cs.tcd.ie> <99AAA0DC-8C1C-451D-9F41-5BF1744EB6EF@akamai.com> <CABcZeBPvEAFZ6mn2-DmBygti2SkGmVThkL45Dk49DrZ9x9Ja_g@mail.gmail.com>
In-Reply-To: <CABcZeBPvEAFZ6mn2-DmBygti2SkGmVThkL45Dk49DrZ9x9Ja_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.13.0.181109
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.107]
Content-Type: multipart/alternative; boundary="_000_1E8AA9CB3BCE45EFA45474D547E80397akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-21_01:, , 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=714 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811210031
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-21_01:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=699 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811210031
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I-XHC44SEZB9F1Th_qlPJdgEowU>
Subject: Re: [TLS] ESNIKeys over complex
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: Wed, 21 Nov 2018 03:40:15 -0000

  *   No, I don't think so. The server might choose to not support one of the TLS 1.3 ciphers, for instance. And even if that weren't true, how would we add new ciphers?

Standard TLS negotiation. I don’t see that we need to specify ciphers at the DNS layer. A client with new ciphers will add it in the hello message and the server will pick one it supports.  It seems complex and fragile (keeping the server cipher config, not just the fronted hosts, in sync with DNS).

v2.23.0 | Report a Bug | By Email