IETF Logo Mail Archive

Re: [TLS] Tonight's Encrypted SNI Hangout Session

Christian Huitema <huitema@huitema.net> Mon, 13 November 2017 19:55 UTC

Return-Path: <huitema@huitema.net>
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 BBFF3129601 for <tls@ietfa.amsl.com>; Mon, 13 Nov 2017 11:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hfndVZ1aGcvv for <tls@ietfa.amsl.com>; Mon, 13 Nov 2017 11:55:16 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D65131241F3 for <tls@ietf.org>; Mon, 13 Nov 2017 11:55:15 -0800 (PST)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eEKp6-0007DG-Br for tls@ietf.org; Mon, 13 Nov 2017 20:55:13 +0100
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eEKoz-0000hZ-9f for tls@ietf.org; Mon, 13 Nov 2017 14:55:09 -0500
Received: (qmail 8191 invoked from network); 13 Nov 2017 19:55:03 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 13 Nov 2017 19:55:03 -0000
To: tls@ietf.org
References: <CAPCpN4t4m9M6u=E29u=TQnBScjRTfA91K9pdyPG3nvyi+GHC3w@mail.gmail.com> <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com> <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <ab71e7d7-1690-776f-47e9-0001e41aef39@huitema.net>
Date: Mon, 13 Nov 2017 11:54:59 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.28)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qTpo3psabwjYwhu6FVK6CkXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4ZaBy1gWP4lJKnrCob7yd4mLB67TLnlh9i6Dr2tTQ7u+oqs y1PKTVoO8Zj6z/ewaDOZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC4SKZ4XAkDTqt5ctPp8cLLgmjn7L5t7To3abBdiYtm1 8d3OLxVbVvBI1Bn6ZETDJ4pZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWWHzJf22XqcXsJzuDdEgoxaf4b0gaZx7Nq9QqOn1O3qTB NY7E/+ds1swbTxxbyGWfEug0a3yzaqY4/fzPDRH3NCG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhVdgmqeRHVgu2HeXOPcfcJVAxXqQU4SUCmX1X8Fu4HDEINFmBCcViSrRI4uua/GkXQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3bWSeyaxwS2RBtS6AHKztnz_YG0>
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 13 Nov 2017 19:55:18 -0000

On 11/13/2017 11:11 AM, Ilari Liusvaara wrote:

> And yes, genuine encrypted SNI could be somewhat nasty for routing
> before terminating TLS. And if one tries to simply use public-key
> encryption, AFAICT, all the known ways are either slower than
> ECDH-ES or have much larger size overhead (heck, ECDH-ES itself is
> either optimal size-wise or close to it). Also, DH-ES type schemes do
> not work with PQC (which is starting to be a concern).

The current draft
(https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/)
studies this problem and describes classes of solutions. The solutions
are certainly imperfect, but they address the use case where a
"multiplexed server" receives requests for a hidden service, when the
SNI in the client hello describes a forwarding service. The draft does
not give examples of what the "multiplexed server"might be, but the
common implementation in our mind is a set of servers behind a load
balancer.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email