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 >
- [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Watson Ladd
- Re: [TLS] Encrypted SNI Viktor Dukhovni
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Salz, Rich
- Re: [TLS] Encrypted SNI Tom Ritter
- Re: [TLS] Encrypted SNI Tom Ritter
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Jacob Appelbaum
- Re: [TLS] Encrypted SNI Salz, Rich
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Ilari Liusvaara
- Re: [TLS] Encrypted SNI Richard Barnes
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Ryan Sleevi
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Ilari Liusvaara
- Re: [TLS] Encrypted SNI Benjamin Kaduk
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Eric Rescorla