Re: [dane] Reusing TLSA

Ben Laurie <benl@google.com> Wed, 26 September 2012 15:06 UTC

Return-Path: <benl@google.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 F2F3321F8658 for <dane@ietfa.amsl.com>; Wed, 26 Sep 2012 08:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 tcLhSLIp887V for <dane@ietfa.amsl.com>; Wed, 26 Sep 2012 08:06:22 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41221F84C4 for <dane@ietf.org>; Wed, 26 Sep 2012 08:06:22 -0700 (PDT)
Received: by obqv19 with SMTP id v19so833073obq.31 for <dane@ietf.org>; Wed, 26 Sep 2012 08:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=bHZU2jOHC4VJsnO7GMMTuVCiBY6wDWkd8An3qWmIdA0=; b=cjN032iy5UbBn4qLwanGeVSaMUy2EHY/WuilkxPkNLMG0mQEnLwFIsIYZnoy2/5Yok NaymOF8APSKIbUX0uObdHiTEU2/2ZmHylKCK2Q4WPDK6/c1xRHjSRUeR3X6NFuMGey4w JAm6kHtz+WuBq1VmRvr/je5Ottqvg9vO6VvTwVKxvfntMewdlHK7ngQYMz1CzEudUnak rIKBKI5EUi6fxyND8ENjTSd/8N53UEnnQSMYmL2JAM1nd3zEemxU9ZW/0YLi75g+cpyC kTg7hz5YEOKGHCvUFfN4AojjeuWxPoJFN+luxdMbu0Dc2mvdgLq6oktQcKFK+jEuaoKa syKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=bHZU2jOHC4VJsnO7GMMTuVCiBY6wDWkd8An3qWmIdA0=; b=VXYo5h6oMG3fAc7e3nttYiSbyc0ktT93tu6c811ugcUz+foTJKfoCB1u2kyKvIwaEv 3peVz6dkYOuEarOw4L/XgzG7gJwnsD+ZlujOj5rXV7uJDEDasTOXP6LCHkfa9n3cGAzm 0A26JJTwTTbPJbBeHhsYOTzuBT9zfdGV1QCZbXDb1rGDxEdsp3RaCjUzIHAm9+PBo290 bLKLm+c6Im4/kLustnlK9S8Y92FxCgk7L6a+wbg1/uiMv8uKWKok+7bh3l/zd8or268d BXdrkTJxQvKw94PYSr4RXDK1UlFDIu8xeD3X4lav04m/sJDpNnUH5TATgqjPRQWER/9/ v1Nw==
Received: by 10.60.20.197 with SMTP id p5mr692036oee.32.1348671974976; Wed, 26 Sep 2012 08:06:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.20.197 with SMTP id p5mr692026oee.32.1348671974866; Wed, 26 Sep 2012 08:06:14 -0700 (PDT)
Received: by 10.60.39.136 with HTTP; Wed, 26 Sep 2012 08:06:14 -0700 (PDT)
In-Reply-To: <19800D41-820B-4256-8C41-0B6854A34AD3@vpnc.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>
Date: Wed, 26 Sep 2012 16:06:14 +0100
Message-ID: <CABrd9SRkE2KuzypFJbDo4XUzGtfdeA-UFMGChM8ktSLwJquCvQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm3PSH9TbYhtVGJ4XL0iZ/Y93KpSw3+uvI7nis0were5xcpL7JX7a8rwpxVpyBd6bP/zKdLVMua5gkSk7LACz4cmSqd8YDfiLnM5tfM6+G7dzDyh/Jm42XK5wxP8nFvAg4dbcMYpd/UwACz8pW0LSvgWhRs11bqf6pEH1w7nMOxVv0qOpKDNu0LdArUAzG6xO90EXea
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:06:23 -0000

On 26 September 2012 15:56, Paul Hoffman <paul.hoffman@vpnc.org> 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?
>
>>>> 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?
>>>
>>> That's not content, that's the request you used to get the content.
>>>
>>> As Ben pointed out earlier, we need to make a few changes saying "where DANE talks about a chain sent by the server, this document is talking about a chain sent by the other party". But the contents are the same.
>>
>> You could argue that all RRs merely contain bytes, so their contents
>> are "the same".
>
> No, you can't. The TLSA RR has particular fields with particular structure. That structure is identical in SMIMEA.
>
>> If they mean different things, then they're not
>> _really_ the same.
>
> Nor do they need to be _really_ the same, just have the same format.
>
>> It could be that TLSA could be redrafted to fix this problem.
>
> It sounds like that a new RFC can update the TLSA draft. That's exactly what we are proposing. :-)

I am more than happy for our different brands of pendantry to coexist
in this case :-)