Re: [dane] Call for Adoption: draft-hoffman-dane-smime.

Richard Barnes <rbarnes@bbn.com> Mon, 24 September 2012 14:39 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A7F21F878E for <dane@ietfa.amsl.com>; Mon, 24 Sep 2012 07:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.74
X-Spam-Level:
X-Spam-Status: No, score=-106.74 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN18E+bqKzUq for <dane@ietfa.amsl.com>; Mon, 24 Sep 2012 07:39:26 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF021F878A for <dane@ietf.org>; Mon, 24 Sep 2012 07:39:25 -0700 (PDT)
Received: from [128.89.253.48] (port=57292) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1TG9oi-0000Wa-Kj; Mon, 24 Sep 2012 10:39:24 -0400
Date: Mon, 24 Sep 2012 16:39:24 +0200
From: Richard Barnes <rbarnes@bbn.com>
To: Miek Gieben <miek@miek.nl>
Message-ID: <8A01227AE22A4EA9BB387AF46A50A74E@bbn.com>
In-Reply-To: <20120924142732.GB9495@miek.nl>
References: <BCDB44B9-6AB0-4230-B1EF-FDDB37C77F38@kumari.net> <357AB2FD-DF7E-49EC-B3D6-D0F6BC20A79F@kumari.net> <C93F9961257B4ADFA226AD8C89290362@bbn.com> <20120924134925.GA9495@miek.nl> <F98183AFDDFD449982489E5D3AB81534@bbn.com> <20120924142732.GB9495@miek.nl>
X-Mailer: sparrow 1.6.3 (build 1172)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5060709c_47398c89_7b3"
Cc: dane@ietf.org
Subject: Re: [dane] Call for Adoption: draft-hoffman-dane-smime.
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 24 Sep 2012 14:39:26 -0000

On Monday, September 24, 2012 at 4:27 PM, Miek Gieben wrote:
> [ Quoting <rbarnes@bbn.com (mailto:rbarnes@bbn.com)> in "Re: [dane] Call for Adoption: draft..." ]
> > New RRs are not *that* cheap. Yes, servers and resolvers usually do let you
> > provision arbitrary RR types by number, but that's not nearly as nice as having
> > a real syntax, which takes time to develop and deploy. If you've got TLSA and
> > you just need people to look for it in a different place, why bother going to
> > the effort of making everyone support a new type?
> > 
> 
> 
> Fair enough. Looking back in the -00 there is even:
> 
> 2.2. Format of the Resource Record
> 
> [[ This will be the same as for TLSA because there is no reason for
> the two to diverge. Lots of text lifted from the TLSA document. ]]
> 
> Which would further proof your point about reusing TLSA. 
> 
> But what about other SSL-like protocols (if/when they are defined for DANE
> use). Should they also re-use TLSA or always use a prefix label? It would
> be nice to get some kind of constency, either they *all* use TLSA or they
> *all* use a prefix label.
> 
> 

There's a saying that goes, "We'll cross that bridge when we come to it." :)

Do you have an example of such a protocol?

--Richard