Re: [ietf-dkim] New issue: DNS Record type for SSP

[Scott Kitterman <[e-mail]>]

On Monday 16 April 2007 20:43, Jim Fenton wrote:
> There have been many discussions regarding the choice of DNS record type
> for SSP.  draft-allman-dkim-ssp proposes the use of a new RR type for
> SSP records; another choice is to use TXT records with a distinct (and
> likely IANA-registered) prefix.
>
> Phill Hallam-Baker has proposed that DKIM policy be queried in two
> different ways, in parallel:  (1) Prefixed query for TXT record, e.g.,
> _dkimpolicy.example.com and (2) Non-prefixed query for a new RR, either
> an XPTR or a new RR containing DKIM policy directly (depending on what
> we decide about the XPTR proposal).  The second query allows the client
> to determine that the domain doesn't exist if it receives an NXDOMAIN
> error.
>
> Argument Pro:  Allows DKIM policy to work in the absence of support for
> new RRs.
>
> Argument Con:  Twice as many queries.  Depending on where it is assumed
> that DNS will not support new RR types, it may never be possible to
> remove support for the TXT query.  If the problem supporting new RRs is
> only with DNS publication, clients will always need to make both kinds
> of queries, although at some point it may be possible to make the
> queries sequential, and only making the TXT query if the query for the
> new RR returns a NODATA response.  If the problem supporting new RRs is
> only with DNS resolvers, it may never be possible to remove TXT records
> and double-publication will always be needed.
>
> My opinion:  Basically "Argument Con" from above (I wrote it, after
> all...).  Allowing the query to make use of an NXDOMAIN response (which
> means there can't be a prefix) I believe to be a useful optimization
> especially in the presence of messages from non-existent domains or
> subdomains; we want to handle this case efficiently because it is a
> likely attack vector.

If the protocol is supportable through use of prefixed TXT records, you'll 
never move off of it.  Give up and don't bother defining the new RR type.  
It's twice as many queries for no gain.  We are near the 2nd aniversary of 
the SPF record type and it still has almost zero deployment.

I tend to think along the lines of make TXT work.  It's all you've got for 
near term deployment.  If we can wait 5 years for SSP, why bother to expend 
the resources to design it at all.

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