Re: [dane] Reusing TLSA

Dan York <dan-ietf@danyork.org> Wed, 26 September 2012 15:34 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 CA18621F845A for <dane@ietfa.amsl.com>; Wed, 26 Sep 2012 08:34:29 -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 vCjo0wq2V2BI for <dane@ietfa.amsl.com>; Wed, 26 Sep 2012 08:34:28 -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 C36DB21F844E for <dane@ietf.org>; Wed, 26 Sep 2012 08:34:19 -0700 (PDT)
Received: by qaec10 with SMTP id c10so5437141qae.10 for <dane@ietf.org>; Wed, 26 Sep 2012 08:34:19 -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=dq0UIJcq5cSv8a3eRnDRLkIV7kggU8Qe9VtMORngpEQ=; b=R4I26zoEgPpsSPelpzMoJE4py6zjvAChnl0B8MJ9Qaa4pB4+/rOstVw591wxyGyut/ R5xG62lu0S82XkJsbmwcjgxylorfXExO6EOqKZ3JSobiOqNAKkFK9Ma2vO+Z69sjl+s1 rOgDTMkgoAO4Dy9rrISv25dXBZbSoetFpLCpoWuLOYrMtbioOL2RidTSUUDGOIn3W52J 77yi8jvJi0O2wqbdzHU8VxV7U2B2tXPrNw4XyyjdHmw/39U7RQbJaNWdIH765jW2BFTp RKqN4ofGdt764QBtwcGfKJZYfvOhp3+TzM5XBybfQvOP4w3sgpUCGJFqJ6k9JC7jW+/k a24g==
Received: by 10.229.137.70 with SMTP id v6mr586401qct.69.1348673659174; Wed, 26 Sep 2012 08:34:19 -0700 (PDT)
Received: from ?IPv6:2001:470:1f07:309:e55d:fa6b:c47b:a985? ([2001:470:1f07:309:e55d:fa6b:c47b:a985]) by mx.google.com with ESMTPS id ck18sm5106201qab.7.2012.09.26.08.34.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 08:34:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_212E18C2-13BF-4396-A43B-8E7DD2242133"
From: Dan York <dan-ietf@danyork.org>
In-Reply-To: <19800D41-820B-4256-8C41-0B6854A34AD3@vpnc.org>
Date: Wed, 26 Sep 2012 11:34:16 -0400
Message-Id: <CBE06D6B-2022-4151-830C-AB43AF9CE5E8@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> <57867BCC-8E8C-4F5A-9A83-0A31652CD71F@danyork.org> <2D645BD5-3501-4182-AB5B-035240F464AA@vpnc.org> <CABrd9STJu_U3Aw5MYjhbZ9Q4SpoM37yUVW5uqyk3aOZyoMvvTg@mail.gmail.com> <19800D41-820B-4256-8C41-0B6854A34AD3@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmzR358Wukop8zhNoSSIBRsGPy3Zi9VfxVmFvjMC3evZwYXiGhX0MiEgPDKOHw08lu9P4qX
Cc: IETF DANE WG list <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: Wed, 26 Sep 2012 15:34:29 -0000

Paul, 

On Sep 26, 2012, at 10:56 AM, Paul Hoffman wrote:

> On Sep 26, 2012, at 1:46 AM, Ben Laurie <benl@google.com> wrote:
> 
>> On 25 September 2012 23:32, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>> On Sep 25, 2012, at 12:06 PM, Dan York <dan-ietf@danyork.org> wrote:
>>> 
>>>> 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?
>>> 
>>> No, because the types of content are identical.
>> 
>> They are not, as I just pointed out in the other thread.
> 
> Unless I missed it (certainly a possibility), what you pointed out was different semantics for identical content. That is, where the RFC talks about the trust anchor for the server, and chains sent by the server, we need to change that to trust anchors used by, and chains sent by, the sending party. No bits on the wire change, right?

My comments were reacting largely to Tony's comment about the content of the TLSA record:

> 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.

To me it just seemed that there could be app developer confusion if in the one case the TLSA record is a digest of a certificate and in another case the TLSA record might be a full certificate.

Having said that, I've now gone back and re-read RFC 6698 and seen clearly that this is all covered with the Matching Type field in section 2.1.3 and so any "DANE implementation" needs to be able to understand both the digest and the full certificate.

So consider my comments withdrawn.... and thanks for the replies that forced me to deepen my understanding of the DANE protocol. :-)

Dan

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