Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

mrex@sap.com (Martin Rex) Fri, 25 September 2015 17:11 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08491A89B0 for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 10:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 UpSXgyhd8H9R for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 10:11:00 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDCF1A854B for <tls@ietf.org>; Fri, 25 Sep 2015 10:10:39 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 08F322B120; Fri, 25 Sep 2015 19:10:38 +0200 (CEST)
X-purgate-ID: 152705::1443201038-00000827-3594EB60/0/0
X-purgate-size: 1132
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id EDEEA4065F; Fri, 25 Sep 2015 19:10:37 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E50EE1A2A1; Fri, 25 Sep 2015 19:10:37 +0200 (CEST)
In-Reply-To: <20150925170003.B24451A2A1@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Fri, 25 Sep 2015 19:10:37 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150925171037.E50EE1A2A1@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mGm3BZgtHC9gaRzvg2GIff1m6S0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 25 Sep 2015 17:11:02 -0000

Martin Rex wrote:
> Salz, Rich wrote:
> > 
> > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> > a proposal that makes SNI-encryption something that can be deployed and
> > tested on the Internet in TLS 1.3.  So we'll see if it gets used and works.
> > The earlier slides notwithstanding, it's something we
> > (those of us at Akamai) would really like to see.
> 
> I haven't been tracking the TLSv1.3 proposals -- but whatever you do
> in the area of encrypted SNI, please ensure that padding *WILL* be used,
> so that two encrypted server names, that happend to differ by length,
> will not remain easily distinguishable.

Because it is not necessarily immediately obvious, you will need
padding also for the Server Certificate handshake messages.
And, because the key exchange is side-effected by properties of
the Server Certificate, you may additionally need padding for the
ServerKeyExchange and ClientKeyExchange handshake messages, so
that the protocol doesn't leak of one of the service uses
an RSA certificate and the other uses an ECDSA (or EdDSA) certificate.

-Martin