RE: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

> From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com] 
> There's a different situation for key records and
> policy/practice/(petunia?) records.  The choice of whether to 
> use a new RR or a TXT key record should be retrieved is 
> something that can be represented in the signature (the query 
> type, q=, tag has been suggested which makes sense).
Absolutely, I have no problem with the idea of using binary key records for
future key formats.

My basic strategy here is as follows

1) Deploy DKIM based on technology that is 110% compatible with legacy DNS
infrastructure.

1a) Deploy a bunch of other technology on the back of DKIM such as secure
Letterhead that creates a compelling and highly visible use case for DKIM.

1b) Begin experimental pilot deployments of DNSSEC to begin build out of
necessary support infrastructure


2) Deploy DNSSEC using the need to secure DKIM records as the critical pain
point to be urgently addressed.

2a) Since DNSSEC requires deployment of infrastrufture that is capable of
handling new RRs the RR deployment issue is at this point moot

2b) Deployment of DNSSEC also effectively increases the maximum size of DNS
packets, even the3 Windows DNS servers have a default greater than 1K

2c) The value of moving from RSA 1024 to RSA 2048 or DSA 2048 is not as
great as the value of moving from RSA 1024 without DNS SEC to RSA 1024 with
DNSSEC. Ergo making DNSSEC a prior deployment requirement for deployment of
longer key sizes is not a concern to me.


3) Deploy options for additional cryptographic algorithms, possibly making
use of binary RRs.


In other words there is a deployment strategy for both phases. The first
phase creates the pain point that motivates the second deployment phase
which in turn enables the third deployment phase.


Any transition to use of binary policy records is in my view unnecessary and
likely to create more problems than it solves. It would be necessary to
publish the records in both formats during the transition period. The DNS
infrastructure makes extensive use of caching, Inconsistency and race
conditions are certain to result from such a switch.

The only drawback identified with prefixed TXT records is the fact that it
is not possible to specify a wildcard of the form _prefix.*.domain. As I
have demonstrated on several occasions this drawback is eliminated through
the use of a PTR record as an indirection wildcard.


The TXT architecture has the advantage of separating the definition of
policy semantics from the internal workings of the policy distribution
platform. The DNS area has repeatedly expressed its desire to avoid
contaminating the core DNS with individual protocol semantics. The
applications area shows a clear need for such semantics to be defined. The
TXT architecture achieves the necessary separation of concerns.

smime.p7s
Description: S/MIME cryptographic signature

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