Re: [ietf-dkim] New Issue: Use of XPTR records in SSP

Douglas Otis <dotis@mail-abuse.org> Tue, 17 April 2007 16:45 UTC

Return-path: <ietf-dkim-bounces@mipassoc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqnj-00078G-VZ for ietf-dkim-archive@lists.ietf.org; Tue, 17 Apr 2007 12:45:08 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hdqni-0002SM-Gl for ietf-dkim-archive@lists.ietf.org; Tue, 17 Apr 2007 12:45:07 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l3HGgg2j025887; Tue, 17 Apr 2007 09:43:12 -0700
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l3HGg86F025779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Tue, 17 Apr 2007 09:42:08 -0700
Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l3HGg8AK028755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2007 09:42:08 -0700
In-Reply-To: <462415FC.9000807@cisco.com>
References: <462415FC.9000807@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F814A440-D552-4A58-806E-BF33013F20E4@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] New Issue: Use of XPTR records in SSP
Date: Tue, 17 Apr 2007 09:42:08 -0700
To: Jim Fenton <fenton@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Songbird: Clean, Clean
Cc: "ietf-dkim@mipassoc.org" <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

On Apr 16, 2007, at 5:34 PM, Jim Fenton wrote:

> This is the first of a few issues that come in trying to  
> rationalize at least two of the SSP proposals, draft-hallambaker- 
> dkimpolicy-00 and draft-allman-dkim-ssp.  I'd like to keep the  
> issues separate, because I think they're largely independent, so  
> please respond in kind if at all possible.

This assumes a simple authorization scheme is not effective at  
protecting a principal domain.  For example, if the industry creates  
a list of domains used for the purpose of registries, then this would  
identify precisely which domain should be queried.  As there are some  
TLDs publishing MX records, such a list becomes even more important  
from the prospect of limiting the scope of TLDs with respect to DKIM  
sub-domain validations.

> =====
>
> Phill Hallam-Baker has proposed the publication of a new PTR-like  RR
> type, tentatively called XPTR, in order to improve the scalability of
> the SSP mechanism to a large number (~1000?) of additional types of
> policy in the future.  To look up the signing policy of  
> example.com, the
> sequence would be:
>
> 1.    Query for XPTR record for example.com.  If result is an NXDOMAIN
> error, the domain does not exist.  If result is a NODATA error, either
> the policy or the domain does not exist.
> 2.    Query for [RRtype TBD; separate issue] record for
> _dkimpolicy.{result of XPTR query}; policy record is stored at that
> location.
>
> Argument Pro:  Supports a potentially very large number of  
> policies, as
> might be needed for WS-* (for example) in the future.  Permits a  
> central
> point of control and modification for policies relating to different
> classes of nodes in the domain.
>
> Argument Con: Requires an additional lookup per query; other types of
> policy are out of scope for the WG.

This is a clever idea, but perhaps a bit late in DNS's evolution.   
The additional overhead is unlikely to become automated, or even  
supported within the corporate environment.  From a DDoS perspective,  
any wildcard scheme can be perilous.

As an industry, establish a list of domains used by registries.  This  
approach facilitates rapid discovery of any number of record types,  
and not just policy related records.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html