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.
- [TLS] Privacy considerations - identity hiding fr… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Eric Rescorla
- Re: [TLS] Privacy considerations - identity hidin… Paul Wouters
- Re: [TLS] Privacy considerations - identity hidin… Eric Rescorla
- Re: [TLS] Privacy considerations - identity hidin… Badra
- Re: [TLS] Privacy considerations - identity hidin… Viktor Dukhovni
- Re: [TLS] Privacy considerations - identity hidin… Paul Wouters
- Re: [TLS] Privacy considerations - identity hidin… Viktor Dukhovni
- Re: [TLS] Privacy considerations - identity hidin… Pascal Urien
- Re: [TLS] Privacy considerations - identity hidin… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Eric Rescorla
- Re: [TLS] Privacy considerations - identity hidin… Eric Rescorla
- Re: [TLS] Privacy considerations - identity hidin… Viktor S. Wold Eide
- Re: [TLS] Privacy considerations - identity hidin… Viktor Dukhovni
- [TLS] Encrypted SNI (was: Privacy considerations … Dave Garrett
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Viktor Dukhovni
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Salz, Rich
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Dave Garrett
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Salz, Rich
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Daniel Kahn Gillmor
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Jacob Appelbaum
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Dave Garrett
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Joseph Lorenzo Hall
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Salz, Rich
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Nick Mathewson
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Salz, Rich
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Martin Rex
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Martin Rex
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Salz, Rich
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Dave Garrett
- Re: [TLS] Encrypted SNI (was: Privacy considerati… Dang, Quynh