Re: [TLS] Encrypted SNI
Toerless Eckert <tte@cs.fau.de> Fri, 02 June 2017 13:28 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3AB5612EB94; Fri, 2 Jun 2017 06:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ld8XoVly1tJt; Fri, 2 Jun 2017 06:28:37 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AB012EB86; Fri, 2 Jun 2017 06:28:37 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C4A7258C4B0; Fri, 2 Jun 2017 15:28:33 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A3A23B0C195; Fri, 2 Jun 2017 15:28:33 +0200 (CEST)
Date: Fri, 02 Jun 2017 15:28:33 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
Cc: Richard Barnes <rlb@ipv.sx>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, Benoit Claise <bclaise@cisco.com>, "sec-ads@ietf.org" <sec-ads@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, ops-chairs@ietf.org
Message-ID: <20170602132833.GE12522@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> <CAL02cgS+eym_=TNupJo0f0qAFgZc14rXNfO=VdGzRX28jXVqkQ@mail.gmail.com> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <CAErg=HG8NFmuX7NUR3tLXbstzj2Spgc_dyh6b5DZqCFh73dt=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAErg=HG8NFmuX7NUR3tLXbstzj2Spgc_dyh6b5DZqCFh73dt=Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sU8MCdNnnhs7YGQ7bMfFL_63-4g>
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 13:28:38 -0000
On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > If a web service hoster does not provide any useful demultiplexer then it > > can of course not > > expect not to get blacklisted across services. Is it not already common > > practice to assign > > separate certificates to separate "web customers" ? > > No. It's typically the opposite. Thanks. Btw: does TLS 1.3 mandate server side cert encryption or is this something server apps can decide ? Just because shared web services may not yet leverage the ability to use certs to authenticate network connections well doesn't mean that that option should not be given to apps. And it would be sad if one would have to revert to older protocol options to have that functionality. Another candidate use case coming to mind eg: auditing tht is required in many eg: financial environments. In the past i have seen even the requirement for the whole data streams to be unencrypted for auditing. Maybe that market segment would also be able to get more privacy but maintain a relevant level of auditing if the auditing relevant class of information was visible via the cert. Cheers Toerless
- [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