Re: [dane] Reusing TLSA

Dan York <dan-ietf@danyork.org> Tue, 25 September 2012 19:06 UTC

Return-Path: <dan-ietf@danyork.org>
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 70BCD21F8871 for <dane@ietfa.amsl.com>; Tue, 25 Sep 2012 12:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1]
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 fWinvx4woPIU for <dane@ietfa.amsl.com>; Tue, 25 Sep 2012 12:06:56 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E4921F886E for <dane@ietf.org>; Tue, 25 Sep 2012 12:06:56 -0700 (PDT)
Received: by qaec10 with SMTP id c10so4493454qae.10 for <dane@ietf.org>; Tue, 25 Sep 2012 12:06:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=c4CqPhFZiBk0lUiBgHiwWAjz8tFGntsCtGbWrP63QBk=; b=KY4fuiFUKIykHpYWCN4NaAvzg+RwzL1yr6SBu/UFs7qUj/KIU6BMAF1Tpvucyd0nuQ /9bmh1HMDpiA7jU0yBmqaOi10VvBSAU9rBLXJN7DpVXCo26JPp91ILjEQROGGdAPEla8 jV8XrrsRXUdcVQidNMmfA4VfTrD1pVNOdGertvt3wPRSTl8e+10UwxD1rQFMOFRQulGD FE3Z5On/QCiSwhc4mRlVrW+pCpEQ031DqV7Ul1iDAEorgyw+F/RcokhroiCwB1LGGMOY 8CrdBij7QlUgxoP0606wKsJ6Ualyx/L91i95VNdxNUWqLdYm1U5wEL6DDKu4AX+2KBGF gPxA==
Received: by 10.224.190.200 with SMTP id dj8mr42423421qab.73.1348600015462; Tue, 25 Sep 2012 12:06:55 -0700 (PDT)
Received: from ?IPv6:2001:470:1f07:309:c985:582a:dc5b:4c9c? ([2001:470:1f07:309:c985:582a:dc5b:4c9c]) by mx.google.com with ESMTPS id dp3sm1721589qab.21.2012.09.25.12.06.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 12:06:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3614C0D8-0A56-4920-AC67-0EC29507B434"
From: Dan York <dan-ietf@danyork.org>
In-Reply-To: <alpine.LSU.2.00.1209250026150.14585@hermes-1.csi.cam.ac.uk>
Date: Tue, 25 Sep 2012 15:06:52 -0400
Message-Id: <57867BCC-8E8C-4F5A-9A83-0A31652CD71F@danyork.org>
References: <FE6C9DF2-E86E-4CEF-A537-D68C5952B602@vpnc.org> <50609A03.1050507@ogud.com> <alpine.LSU.2.00.1209250026150.14585@hermes-1.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnp3zGWyD33i5St9hQVBa0w0Sx+cMvepBEsgELl/F078+5MVk+d7mxX/XMWg0yi9uyBNkOq
Cc: dane@ietf.org
Subject: Re: [dane] Reusing TLSA
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: Tue, 25 Sep 2012 19:06:57 -0000

On Sep 24, 2012, at 7:32 PM, Tony Finch wrote:

> * Would sharing an RRtype lead to useful code sharing between S/MIME and
> TLS implementations?
> 
>> Reuse of TLSA RR by a protocol means subscribing to supporting new
>> entries in the above registries and even allowing new entries in there
>> that only make sense in one context.
> 
> TLS is about authenticating peers. S/MIME is about encryption as well as
> verifying signatures. So I would expect TLS records to be more about
> digests of certificates (for brevity) whereas S/MIME records to contain
> public keys or entire certs.


As I've been reading this whole conversation I've been struggling with this last kind of point in my brain, mostly because I think of this not in terms of "Using DANE with S/MIME" but rather in terms of "Using DANE with $foo" where S/MIME is merely one of hopefully many different protocols that could work with DANE. (My own personal interest, coming from the VoIP space, is in seeing how it might someday work with SIP.)

I keep coming to three questions:

1. What is the easiest option for developers creating applications?
2. What is the easiest option for infrastructure operators who may be barriers to having those applications work?
3. What is the easiest option for DNS hosting providers where DNS records may be entered?

My worry with #2 is that if we have a proliferation of RRtypes for each value of $foo, we'll wind up with a situation where some infrastructure components (ex. aggressive firewalls) may need to be changed to allow each RRtype to be allowed through.  Similarly for #3, a graphical user interface where people enter records would need to be changed to support each new RRtype.  Some DNS hosting providers might do this quickly, some wouldn't. Either way it's work they have to do.

Sticking with a single RRtype for any "DANE" usage would make these parts far simpler.  Get them to support the "TLSA" record and they're done.

Likewise, for application developers, the use of a single RRtype would potentially allow sharing of code between different $foo implementations.

BUT... to Tony's last point, are we in fact making it *harder* for developers by overloading the TLSA RRtype with different types of content?  Or is that adequately addressed by having the second left-most label in the domain name (ex. "_smimecert") be the way that a developer would know what is in the TLSA RR and therefore how it should be processed?

Still pondering all this,
Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork