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