Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]

Warren Kumari <warren@kumari.net> Fri, 06 December 2013 20:00 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3491AE3BD for <dane@ietfa.amsl.com>; Fri, 6 Dec 2013 12:00:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 QfNHvzfLFwxO for <dane@ietfa.amsl.com>; Fri, 6 Dec 2013 12:00:22 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1C1AE3C1 for <dane@ietf.org>; Fri, 6 Dec 2013 12:00:22 -0800 (PST)
Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 98C6B1B404A4; Fri, 6 Dec 2013 15:00:18 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <20131205175314.GH761@mournblade.imrryr.org>
Date: Fri, 06 Dec 2013 15:00:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E78C07CA-B742-43B2-8848-33DEB22A8014@kumari.net>
References: <A06891E1-01E0-40CC-A9A2-171CAA39AB79@kumari.net> <20131205175314.GH761@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1816)
Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 20:00:26 -0000

On Dec 5, 2013, at 12:53 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> 
> The sample size of responses seems too small to reach a meaningful
> consensus.

Unfortunately both to small, and not all in agreement.

I’m going to extend this LC to Wednesday and suggest that, if we don’t get consensus on this we simply stick with what is in the current (draft-ietf-dane-registry-acronyms-02) document.

We don’t need these names / acronyms to be perfect, simply clearer / easier to remember than the ordinals.

Any (strong) objections?
W

> 
> Perhaps posting something a bit more controversial will get the
> silent majority to speak up. :-)  To wit:
> 
>    - Assign explanatory names only to usages 2 and 3:
> 
> 	2 - TRUST-ANCHOR
> 	3 - END-ENTITY
> 
>    - Since usages 0/1 merely complicate DANE implementation without[*]
>      enhancing security, they can remain anonymous, or be given names
>      that clearly indicate that these are discouraged/deprecated.
> 
> 	0 - SECURITY-THEATRE-0
> 	1 - SECURITY-THEATRE-1
> 
> This would remove all confusion about the DANE usages.  If someone
> can justify the existence of 0 and 1 in a pair of pithy acronyms
> then those are the names.  Otherwise, out they go!
> 
> [ I have begun design/implementation of general-purpose DANE support
>  for OpenSSL.  Supporting all four usages is rather more complex
>  than one might imagine, and is largely wasted effort, but the
>  protocol requires 0/1 for now, so I have no choice.  I would be
>  thrilled to bits were the above to be taken seriously, and usages
>  0/1 dropped from DANE TLSA in a future revision of the protocol. ]
> 
> -- 
> 	Viktor.
> 
> *  If DNSSEC *is not* compromised, 2/3 are sufficient.
> 
>   If DNSSEC *is* compromised, the attacker will publish 2/3, thus
>   a domain owner's use of 0/1 offers no protection against DNS attacks.
> 
>   There will be no measurable deployment of out-of-band mechanisms
>   that harden 0/1 or application protocols that implement DANE, with
>   just usages 0 and 1.
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
> 

-- 
Eagles soar but a weasel will never get sucked into a jet engine