Re: [ietf-dkim] SSP issues

"william(at)elan.net" <william@elan.net> Wed, 30 May 2007 22:56 UTC

Return-path: <ietf-dkim-bounces@mipassoc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX62-0005lh-GW for ietf-dkim-archive@lists.ietf.org; Wed, 30 May 2007 18:56:50 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtX62-0006PL-45 for ietf-dkim-archive@lists.ietf.org; Wed, 30 May 2007 18:56:50 -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 l4UMttWi029280; Wed, 30 May 2007 15:55:55 -0700
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4UMtnFW029264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Wed, 30 May 2007 15:55:49 -0700
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l4UNsZhx017813; Wed, 30 May 2007 16:54:35 -0700
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l4UNsZxT017810; Wed, 30 May 2007 16:54:35 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Wed, 30 May 2007 16:54:35 -0700
From: "william(at)elan.net" <william@elan.net>
To: Jim Fenton <fenton@cisco.com>
Subject: Re: [ietf-dkim] SSP issues
In-Reply-To: <465DF93D.1080306@cisco.com>
Message-ID: <Pine.LNX.4.62.0705301647120.9976@sokol.elan.net>
References: <465DF93D.1080306@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Songbird: Clean, Clean
Cc: IETF DKIM WG <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: 4adaf050708fb13be3316a9eee889caa

On Wed, 30 May 2007, Jim Fenton wrote:

> What we had hoped to do in the next revision of the allman-ssp draft was to unify it as much as possible with Phill Hallam-Baker's draft.  I opened three new issues on April 16 that I think need to be resolved in order to do that.
>
> (1) Use of XPTR records for SSP.  The idea here is to create a more 
> general policy mechanism that can be used by WS-* and such.  There were 
> about 20 messages discussing this from 5 people.  I'm not reading a 
> clear consensus on this.

This should not be handled as part of this WG but within dns group.

> (2) SSP record type (TXT vs. something new). Only 4 messages in 
> discussion, mostly saying "if you support TXT, don't bother with 
> anything else."  Again, no clear consensus.

If you need another opinion, do both TXT and custom record.
I guess that does not help your consensus searching though...

> (3) Upward query vs. wildcard publication.  27 messages in discussion 
> from 15 people.  Most of the discussion was a rehash of the idea of 
> associating semantics with DNS zone-cuts, which we had already discussed 
> and rejected.  I have also been trying to get an opinion from DNSOP on 
> the idea of a one-level upward search (which I think solves 90% of the 
> problem), but haven't gotten any response.

Dont do it. The issue is that you can not properly tell where zone
delegation starts. I know resourceful programmers (including me)
keep track of this data and know that for example ".com" is one
delegation but ".uk" is not and there you have ".co.uk". But the
list is actually rather large and for several ccTLDs you have both
use ".com.??" and ".??" as proper delegation zones. So getting
around this is just way too tricky and if you don't what you end
up doing is sending multitude of extra queries to ccTLD name servers.
This is not proper operational approach as extra load would not be
spread but directed towards several single points on the net.

> So I don't know what to write in a revision of the draft.  I could just write my opinions, but that's basically what's in the draft-allman-dkim-ssp-02 draft already and doesn't make any progress toward unifying the different proposals.  I want to get something done soon, well before the July 2 deadline.
>
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html