IETF Logo Mail Archive

Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt

Matt Miller <mamille2@cisco.com> Fri, 08 June 2012 17:02 UTC

Return-Path: <mamille2@cisco.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 A627F21F88C5 for <dane@ietfa.amsl.com>; Fri, 8 Jun 2012 10:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.454
X-Spam-Level:
X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkkChIIJeWo8 for <dane@ietfa.amsl.com>; Fri, 8 Jun 2012 10:02:14 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4421F88B7 for <dane@ietf.org>; Fri, 8 Jun 2012 10:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5667; q=dns/txt; s=iport; t=1339174934; x=1340384534; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QJxi+qeXXjax3gwXuKQTKnwLxpv6yTvZ4LNKmPdhvw0=; b=QBq3MkJzUFxcfM61n+ADzWenzrq1x9UC8M7pFRSDixIQYD9v1hJbP0dI IGQw9YBer5qRSWyZSZizygOwqk5xSnC1CxKdJEjnF+lUt5VH4yeguLah+ 73PMAkfpwfiF/ZwQBeokz43tElYvRAa9WeK47QGREktvRr4hBItgFd7Ft 8=;
X-Files: smime.p7s, PGP.sig : 2214, 535
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJ8u0k+rRDoI/2dsb2JhbABFtFeBB4IYAQEBAwESAWYFCwsOCi4CVQYTIodkBAGZSJ9oiyaFIGADiECFeIZmhVOIQoFmgn8
X-IronPort-AV: E=Sophos; i="4.75,738,1330905600"; d="sig'?p7s'?scan'208"; a="45098497"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 Jun 2012 17:02:14 +0000
Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q58H1i83027342; Fri, 8 Jun 2012 17:02:13 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-52-90501462"
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <alpine.LSU.2.00.1206081139500.10076@hermes-2.csi.cam.ac.uk>
Date: Fri, 08 Jun 2012 11:02:34 -0600
Message-Id: <8AFED8BC-9E9A-4ED7-950A-5E3579799BAE@cisco.com>
References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <DAFA7185-25CD-452A-A533-C5002B21C4CC@cisco.com> <alpine.LSU.2.00.1206072004470.5807@hermes-2.csi.cam.ac.uk> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> <alpine.LSU.2.00.1206081139500.10076@hermes-2.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Content-Transfer-Encoding: 7bit
X-Pgp-Agent: GPGMail 1.3.3
X-Mailer: Apple Mail (2.1084)
Cc: IETF DANE WG list <dane@ietf.org>
Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt
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: Fri, 08 Jun 2012 17:02:15 -0000

On Jun 8, 2012, at 04:43, Tony Finch wrote:

> Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 
>>>> What is the point of omitting the name check in this case?
>>>> Alternatively, what is the point of including the name check in
>>>> the other DANE cases? My drafts say that name checks should
>>>> still be performed in the usual way, the idea being that DANE
>>>> leads to additional verification code paths rather than
>>>> completely distinct code paths.
>>>> 
>>> 
>>> My thinking was, if we got to this point, then the name in the
>>> certificate was no longer material.  The delegation by the source
>>> domain to the derived domain was already proved, and this check
>>> simply added a technicality to fail on.
>> 
>> Agreed.
> 
> Yes this is a valid argument and I agree. However I also think consistency
> is important. Why would some TLSA usages require name matches and others
> not? Why disable a check done by existing code rather than just adding
> checks?
> 

For Usage 3, the TLS client was effectively told what to match in totality.  I see this check as overly burdensome on deployments, and not very burdensome on implementers.


- m&m

Matt Miller - <mamille2@cisco.com>
Cisco Systems, Inc.

v2.23.0 | Report a Bug | By Email