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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 25 August 2015 02:19 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 3F9791ACD45 for <tls@ietfa.amsl.com>; Mon, 24 Aug 2015 19:19:29 -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 yiFEiU1zsW8E for <tls@ietfa.amsl.com>; Mon, 24 Aug 2015 19:19:28 -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 D05151ACD6F for <tls@ietf.org>; Mon, 24 Aug 2015 19:19:27 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E2DB8284D64; Tue, 25 Aug 2015 02:19:26 +0000 (UTC)
Date: Tue, 25 Aug 2015 02:19:26 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150825021926.GS9021@mournblade.imrryr.org>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CABcZeBNP8SZeWWVj4_fGxZm-SvYG-cmtQoJ1xBaLLWsLKsNc4Q@mail.gmail.com> <alpine.LFD.2.20.1508241730590.31517@bofh.nohats.ca> <20150825011913.GR9021@mournblade.imrryr.org> <alpine.LFD.2.20.1508242155120.6928@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.20.1508242155120.6928@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/RzjqcXwyGJihCRiei99AYvZIOOg>
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: Tue, 25 Aug 2015 02:19:29 -0000

On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote:

> >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
> >>CAs they trust, so unless you receive a hash of a known CA to you, you
> >>can withold your own certificate from being sent.
> >>
> >>Is a similar mechanism not planned for TLS 1.3?
> >
> >This would break DANE, unless the mechanism also allowed the client
> >to send a TLSA RRset instead, with the server then needing code to
> >figure out which chains match which TLSA RRs.  This is I think too
> >complex.
> 
> If you publish your public key in DNS you would also just always
> send your public key over TLS. There is no privacy issue there,
> so no reason to withhold it.

Not sure how this comports with your original proposal.  What would
a client have to send to convince the server to not withold its
certificate?  What does witholding it mean anyway, the client needs
the public key at least if the server signs the key exchange.  Is
there something here worth pursuing in the context of TLS?

-- 
	Viktor.