Re: [TLS] Encrypted SNI

Richard Barnes <rlb@ipv.sx> Fri, 02 June 2017 10:16 UTC

Return-Path: <rlb@ipv.sx>
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 6F47612EB1D for <tls@ietfa.amsl.com>; Fri, 2 Jun 2017 03:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 ky6dSstplGR7 for <tls@ietfa.amsl.com>; Fri, 2 Jun 2017 03:16:07 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBAC12EB26 for <tls@ietf.org>; Fri, 2 Jun 2017 03:16:03 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id b84so20078711wmh.0 for <tls@ietf.org>; Fri, 02 Jun 2017 03:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoAE/OUPnfbS71im5mP1QXyapBn14Kh6Lz9X+NEAIao=; b=TOHr5L8ZRn8irWJvpOLv3nkUd/iWhc7WZ6pZIxyzyt+d2zDWIzD4Y7l/FWyyLIN8M5 KiCK85bTAswTpHkBZgIRL3NLCTefji5+JYLjex81HhXIXodM55dVvKz2ccRyneh7+0g8 ONJD+fKkPxlEp4elAEnAn0hT2ILE/LGmAF/8rXJWfQ1VerImsLpd8AEb0icGTJiACRL9 46NoZsFTbW2spKBFs+GlTnLcVBancXKGZ7Y5VM+yOhfYhGKzlj+P+V2bAmKX6HwgiyMo PspVG1Qgkcnb3PXj1bwO/Ch3XgepNgTaGf4juaJWbKqZ7bgMUvOtHuzW5SnsK8OxVuoW HZwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoAE/OUPnfbS71im5mP1QXyapBn14Kh6Lz9X+NEAIao=; b=ovqEDMMrzLO6zPVEfSze7V0KyMXkk7q9a6Ni8OTbLVoXyPM6aio7IYSlA5+V0KLGEn Xmwtlmo1XWz+Odq0cdXpsV+cz/GXOzMnq6ysZGYlI7h0DNfW2pztVi8mXNDKo5rwB5Bb UY3Xt6+9m3UVBF71vpmWyRNOxtBARAJQFn7BbMqgTa1m9WOgdVsfOrwJB9BaItf2+cDx 2MRCqJI0+rY4zqfMzVe4ZMT2+H/Zh+toaWKSiCgnbqmVtHEjEzoPmrVEZQfC6FhSkBcP Gn1k4ZqeqcgXdtRRgPO2Z2CnIfvVS3xDALzTgdI/72/DlTwfkKgO5RY1Jb4oTPkwRi27 EycQ==
X-Gm-Message-State: AODbwcD6oImUdbxLlyAuatLrupMtGGqU4m8oW3DLqVOg9W2UAUVY7fOB YzW8m52VoZ9O4oTXxFvQPx6JhmU/cgugAzI=
X-Received: by 10.223.170.195 with SMTP id i3mr5547649wrc.49.1496398561717; Fri, 02 Jun 2017 03:16:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.109.82 with HTTP; Fri, 2 Jun 2017 03:16:01 -0700 (PDT)
In-Reply-To: <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de>
References: <CAHbuEH4Bwr13T-cBFvLmUmn6KRzuNf1su6VTeJguyssk6S2z3g@mail.gmail.com> <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 02 Jun 2017 13:16:01 +0300
Message-ID: <CAL02cgS+eym_=TNupJo0f0qAFgZc14rXNfO=VdGzRX28jXVqkQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: Benoit Claise <bclaise@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, "sec-ads@ietf.org" <sec-ads@ietf.org>, ops-chairs@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1cbbc0b6c7090550f770ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/X2cl9oshHqoDHrMJ6726w0xwouY>
Subject: Re: [TLS] Encrypted SNI
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: Fri, 02 Jun 2017 10:16:08 -0000

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert <tte@cs.fau.de> wrote:

> 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.


Operators trying to do this by inspecting TLS (and not decrypting) are
going to have a bad time anyway.  With HTTP/2 connection coalescing, even
if they can see the certificate, the actual HTTP request could be for any
name in the certificate.  So there's nothing really gained by exposing the
certificate.

--Richard



> 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.
>
> Cheers
>     Toerless
>
> 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.
> > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> >
> > 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>