Re: [TLS] Encrypted SNI

Toerless Eckert <> Fri, 02 June 2017 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 105EE127A91; Fri, 2 Jun 2017 01:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lWQZHB6t-DyV; Fri, 2 Jun 2017 01:43:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2D8412E042; Fri, 2 Jun 2017 01:43:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 083C458C4F7; Fri, 2 Jun 2017 10:43:01 +0200 (CEST)
Received: by (Postfix, from userid 10463) id D098CB0C189; Fri, 2 Jun 2017 10:43:00 +0200 (CEST)
Date: Fri, 02 Jun 2017 10:43:00 +0200
From: Toerless Eckert <>
To: Benoit Claise <>
Cc: "" <>,, "" <>, "" <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [TLS] Encrypted SNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jun 2017 08:43:08 -0000

Thanks, Benoit

[hope it's ok. to cross-port and redirect replies to TLS]

I have not followed TLS 1.3 in detail, so a quick question first:

Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or
will it force server operators to encrypt either/or ? If it does not permit server applications
to indicate what to encrypt, then i would really love to know which shared web-hosters did
explicitly express support for TLS 1.3.

Use case: (i can't believe this hasn't been discussed _forever_, but i do not subscribe to TLS...)

Operators of "client-side" networks want to be able to enforce policies which "web-services"
their clients can communicate with. As soon as the IP address used to host a web-service runs
multiple web-services (domain-names), this is today done by inspecting the TLS 1.2 server certificate
or SNI. 

Web hosters whose services do share IP addresses across domain name should be very interested to
ensure such inspection works, because else a single misbehaving web-service they host will easily
cause all their web-services to be blacklisted by any of the varied organizations that create 
blacklists: because blacklisting can then only be applied on a per-IP address.

Of course, IPv6 could make this need somewhat obsolete because there should be no reason to
share IPv6 addresses across domain-names, but i am not aware what todays common practice are with IPv6
in this respect.


On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> Dear all,
> You should be aware that the TLS list is debating encrypting SNI so
> that the host name cannot be seen from TLS sessions.
> If you're aware of valid (valid in the IETF-sense) operational
> practices that require the host name visible, we should enter the
> debate.
> Regards, Benoit