ietf-dkim
[Top] [All Lists]

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

2006-03-30 15:30:20
Let us consider the problem of interoperation in stages:

The record is published in DNS server A which is connected to the Internet
by some local network infrastructure travels over the backbone, travels over
some more network infrastructure which may or may not include a DNS server
to the application making the query B.

What is important for compatibility reasons here is the combination of the
infrastructure and A or B respectively. Lets call the combination of A and
the infrastructure connecting it to the open backbone A' and the same for
B'.


If you are operating A then you should know whether A' is or is not a viable
transit channel for new RRs. Either it is going to work or it is not going
to work. If it is not going to work then you SHOULD NOT sign using q=newRR
until you have fixed this.

If you are operating B you should likewise know the capability of your
infrastructure. Attempts to resolve the newRR over B' will either always
succeed or always fail. 


We clearly need to have at least one algorithm that A can use even if their
local infrastructure does not support newRR. RSA1024+SHA256 appears to be
that algorithm.  We are quite likely to want to upgrade to other algorithms,
including RSA2048 and DSA2048. It is quite hard to see how we can get the
base64 encoded key, necessary attribute info, packaging and a DNSSEC
signature into a 512 byte message.

Here we get to a bizare part of deployment strategy. It is much easier to
deploy a security patch than a new security infrastructure. If deployment of
a new DNS server was a precondition to deployment of DKIM it would be DOA.
Once that DKIM service is installed though it becomes much easier to put
deployment of DNSSEC and the necessary upgrades to the infrastructure on the
list.


Key records are different from policy records in another important wat.
Unless it is prefixed the policy record MUST be in the core DNS server. Key
records are much easier to move off to a different service - by design.

I can quite imagine a situation where a CA providing comprehensive support
for DKIM would provide a service providing full feature support in one
package. I.E. host the DNS key records DNSSEC signatures thereof. In that
case it may even be possible to publish under multiple schemes (TXT and
newRR).




-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Thursday, March 30, 2006 4:40 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

3.  verifiers that see q=<newRR> SHOULD query for that RR but MAY 
query for the TXT.

Single query, no matter what the situation.  No failures, 
so no fallbacks.

Right. I conflated the need to support both types by the 
sender with the need for a fallback query. So the fallback is 
eliminated, but the sender may need to support both record 
types forever.

The next question is whether this is a good strategy for RR 
adoption or not and whether that should be considered.


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

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