Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 06 June 2014 15:44 UTC

Return-Path: <viktor1dane@dukhovni.org>
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 76D921A00F6 for <dane@ietfa.amsl.com>; Fri, 6 Jun 2014 08:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 HkMW_CRnRWof for <dane@ietfa.amsl.com>; Fri, 6 Jun 2014 08:44:24 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1231A01DE for <dane@ietf.org>; Fri, 6 Jun 2014 08:44:24 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 494BE2AAB4F; Fri, 6 Jun 2014 15:44:17 +0000 (UTC)
Date: Fri, 06 Jun 2014 15:44:17 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140606154417.GY27883@mournblade.imrryr.org>
References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> <201406060021.s560LiBT019821@new.toad.com> <20140606011121.GS27883@mournblade.imrryr.org> <alpine.LFD.2.10.1406061115290.16748@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1406061115290.16748@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4LzCkxJYuDjMBBJkmqphMBUQBLk
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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 Jun 2014 15:44:26 -0000

On Fri, Jun 06, 2014 at 11:25:26AM -0400, Paul Wouters wrote:

> On Fri, 6 Jun 2014, Viktor Dukhovni wrote:
> 
> >You'll find that there is little support for RPK formats other than
> >"3 1 X", despite a small number of suggestions to the contrary.  A
> >consensus around "3 1 X" is I think a safe bet.

A safe bet that this becomes the standard encoding of RPK TLSA records.

> It is not a safe bet. We only need one external requirement, like PCI-DSS
> or the EV consortium to start dictating one has to publish and match a
> full certificate to get their goodies like a green url bar.

Which little bearing on how to publish the RPK records.

> Then you
> would need a mix of TLSA types to support both the PKIX/CABforum/EV
> universe and raw public keys.

Encoded as "3 1 X" which was the limited scope of that comment.

> And by not allowing that, or by stating
> a mixed TLSA RRset means sacrificing raw public keys, the result would
> force everyone to be stuck with full PKIX validation.

That's a separate question than the one under discussion.  The
hypothetical seems rather conspiratorial.  In a conspiracy more
likely these various actors, if they were acting to thwart DANE
adoption, would simply erect barriers to all use of DANE TLSA.
(Perhaps they're doing that already).  Just preventing use of RPK
seems like a rather modest goal if DANE "3 0 1" and "2 0 1" are
are left standing and become popular.

You can at least relax in my case, I am not part of any X.509
cospiracy. :-)  Rather, I just work to be sure that things actually
work in all cases, including the corner ones.

> In other words, your 'optimization' can be harmful. You're still welcome
> to code that into your software. But you can't standardize it.

Just to be clear I see RPK as an optimization, and my suggested
suppression of RPM with mixed TLSA RRs as forgoing the optimization.

However, we should tackle this point in the new thread I started,
after refocusing the arguement, it seems to be making better
progress.

-- 
	Viktor.