[Cfrg] ReL DANE in the IETF (was: Re: considering new topics for CFRG)

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 09 January 2014 17:47 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4A7A51AE062 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 09:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RrlTmxsI6nJJ for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 09:47:03 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 719991AE05D for <cfrg@irtf.org>; Thu, 9 Jan 2014 09:47:03 -0800 (PST)
Received: from [] (50-1-51-230.dsl.dynamic.fusionbroadband.com []) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s09HQrtM044481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:26:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [] claimed to be []
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7053@SC-VEXCH2.marvell.com>
Date: Thu, 09 Jan 2014 09:46:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B412DDFC-191A-4AEB-B912-A8E798AA5FAF@vpnc.org>
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com> <52CD314B.2000604@cisco.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A1154@MSMR-GH1-UEA03.corp.nsa.gov> <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7053@SC-VEXCH2.marvell.com>
To: Paul Lambert <paul@marvell.com>
X-Mailer: Apple Mail (2.1827)
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] ReL DANE in the IETF (was: Re: considering new topics for CFRG)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 17:47:04 -0000

On Jan 8, 2014, at 5:55 PM, Paul Lambert <paul@marvell.com> wrote:

>> -----Original Message-----
>> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M.
>> Sent: Wednesday, January 08, 2014 10:15 AM
>> To: 'David McGrew'; Sean Turner
>> Cc: cfrg@irtf.org
>> Subject: Re: [Cfrg] QKD is pointless (was: Re: considering new topics
>> for CFRG)
>> I'd like to see the CFRG investigate how far the DANE paradigm can be
>> pushed w/o bringing the system to a screeching halt.
>> For example, there is a group an NIST looking at the possibility of
>> leveraging DANE for use with e-mail.  Who else is out there hoping to
>> piggy bank on DANE?  Can DANE be the new PKI?  
> No. 

Actually, yes it can, if you change your assumptions about what you want "the PKI" to be. The current "the PKI" assumes many things about how many trust anchors there should be and what names each of those trust anchors can vouch for. DANE, as a new "the PKI" makes different assumptions. There are operational advantages to each choice.

> Nice hack, but lacking adequate semantics and constraint based
> architecture to extend well beyond DNS based naming (email could work).

Right: that's exactly the point of DANE. The semantics are purposely limited to the naming scheme people care most about on the Internet. What other names do you think are important for a new "the PKI" that can't be associated with the DNS?

>> If not, what features
>> does it lack & can it be "patched"?
> Anything could be patched ... but the core hierarchy structure
> of DNS would be maintained and would always be of that flavor 
> of that solution space. 

Quite right. That's considered a feature by many.

> I'd like to see something that would work for mobile phones without
> central servers ...

Please say more. Are you assuming a mobile phone not connected to the Internet?

--Paul Hoffman