IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 28 August 2015 14:49 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 A65B01B2D31 for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 07:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Y5mpV2k2sKVB for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 07:49:34 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EEA1B2C5E for <tls@ietf.org>; Fri, 28 Aug 2015 07:49:34 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 09AF2284D24; Fri, 28 Aug 2015 14:49:33 +0000 (UTC)
Date: Fri, 28 Aug 2015 14:49:33 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150828144932.GH9021@mournblade.imrryr.org>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CABcZeBNP8SZeWWVj4_fGxZm-SvYG-cmtQoJ1xBaLLWsLKsNc4Q@mail.gmail.com> <CAL6x8mf6f0_RaUhsXh0dWeB0_=XcCdvbechAcd=q_cq95dB_2w@mail.gmail.com> <CABcZeBN7gXAu8Y7u4aO3_GVTEVqOKJLUBuWcWCOiyDZQxFtGwA@mail.gmail.com> <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zaf8ulevhnI3tOgoKn95lU5Okd8>
Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 28 Aug 2015 14:49:35 -0000

On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:

> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client generally is not authenticated currently, TLS 1.3 and
> DTLS 1.3 are likely to stay for a long time and then to be used for lots of
> different use cases, including more peer-to-peer interaction. For some
> use-cases, including peer-to-peer interaction, being able to progressively
> reveal more information would improve protection. Whether this is a
> worthwhile tradeoff or not, depends on many different factors. I think it
> is both relevant and interesting to see to what extent (D)TLS 1.3 would
> support such use cases.

It seems that with TLS 1.3 the client MUST send SNI, presumably in
the clear.  Typically there's not much else of interest in the
server certificate to hide.  I don't see a realistic way to hide
the server identity even from passive wiretap via TLS.

Encryption of the TCP layer, plus TLS channel-binding (or
super-encryption) might be necessary to limit the metadata leakage
to just the transport layer endpoint addresses.  With IPsec the
leakage is just the network layer addresses.

Is anyone looking into leveraging TCPinc (when available) in TLS?
Extract channel-binding data from the socket, authenticate it with
TLS, and perhaps use TLS with NULL ciphers and if possible a
simplified handshake...

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email