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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Mar 2006 09:27:21 -0800

> From: Hector Santos [mailto:[email-masked]] 

> Follow the MARID May/2004 "Wild Card MXes" Thread at:
> 
> http://www.mhonarc.org/archive/html/ietf-mxcomp/2004-05/msg00504.html
> http://www.mhonarc.org/archive/html/ietf-mxcomp/2004-05/msg00461.html
> 
> Bob Atkinson seems to explain in detail.

Olafur and co are much better at demanding data from others than providing
it themselves.

My bigger complaint here is that this is one case where we know that
significant deployment problems are being swept under the carpet. This calls
into question their claims with respect to UNIX deployment of BIND. 

Experience on the phishing side of the house strongly suggests that there
are a lot of very old BIND servers out there. 

If people write a spec that does not make explicit description of how an
extension mechanism should work and provide detailed implementation guidance
to ensure interoperability they should not be allowed to later claim that
this is the only conceivable, only allowable extension mechanism for the
protocol. 

If DKIM deploys then DNSSEC will be pulled along in its wake which in turn
will drag deployment of the extension mechanism. Making deployment of the
extension mechanism a necessary deployment condition creates a cycle of
ungranted requests, in other words a deadlock. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 30 Mar 2006 04:13:21 -0500

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> If DKIM deploys then DNSSEC will be pulled along in its wake
> which in turn will drag deployment of the extension mechanism.
> Making deployment of the extension mechanism a necessary
> deployment condition creates a cycle of ungranted requests,
> in other words a deadlock.

Phillip,

Just so I can better understand you, overall, due to the unreliability of
proper operations in a wide, generalized DNS server network, you do not
support the introduction of a new RR for DKIM.  Would that be correct?

Also, if it was done, I guess there it would require there be a migration
concept and thus we would have two records; a RR and TXT record.  Thus, from
a client (DKIM implementation) standpoint, it would behave in a try RR
First, fallback to TXT second concept.  Right?  If so, would you consider
this to be too much overhead, making it impractical to expect clients to
operate in this mode?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Mar 2006 10:09:24 -0800

> this to be too much overhead, making it impractical to expect clients to
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).

The retrieval of "P" records is more of a problem, since in general
there's nothing in the message to tell the verifier what to look for. 
This argues in favor of not having two ways to do this.  Alternatively,
a verifier could cache (even beyond the TTL of the DNS records) the type
of record favored by a given domain, as a hint to what to look for first.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Mar 2006 12:04:59 -0800

On Mar 30, 2006, at 10:09 AM, Jim Fenton wrote:

> 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).

Agreed.  The WG can do the right thing and define a binary key for  
future use.  If there are few impediments, the future might be sooner  
than later.

> there's nothing in the message to tell the verifier what to look  
> for.  This argues in favor of not having two ways to do this.   
> Alternatively, a verifier could cache (even beyond the TTL of the  
> DNS records) the type of record favored by a given domain, as a  
> hint to what to look for first.

The policy records might also use PTR RRsets rather than a TXT RR or  
some other new record.  Defining an open or closed-ended list of  
third-party signers provides more essential information than found  
using the current TXT record approach.  The "r=" element should be  
removed.

_tps._dkim.<email-domain>. labels can offer the following information:

"*." = Open-ended.  (Non-exclusive list covering "-" and "~")
"."  = Closed-ended (Exclusive and no list that covers "!")
"-." = Never sends email. (Never and no list that covers ".")

Depending upon whether just the "." is seen or a "*." is found within  
the list, this scheme offers more useful information related to the  
sending domain.

Although a better approach would be to associate the EHLO with the  
signing-domain, the same strategy could be used to associate email- 
address domains with the signing-domain and essentially indicate who  
directly signs this domain's messages.

Here is an example of an exclusive list of signing domains for <email- 
domain>.

_tps._dkim.<email-domain>. PTR my-provider.com.
                            PTR my-other-provider.com.

A list of third-party signers could be used to adjust handling when  
rate-limiting might not be in place, or when the message does not  
appear to be properly signed.

Although this does not scale beyond what can be contained within a  
DNS response, there is name compression.  For large organizations  
wishing to remain silent on who they use, they could either publish a  
list that with just "*." which means others will be signing their  
messages (perhaps the default assumed when no list is seen).  If the  
organization used the "." label, this would mean only that  
organization signs their messages (perhaps they also use key  
delegation).

Just as there were concerns expressed regarding the opaque-identifier  
revocation overhead, the "^" per-user record represents even a  
greater concern!

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 30 Mar 2006 20:23:31 +0000

> represented in the signature (the query type, q=, tag has been suggested

As a practical matter, I don't see how this can actually work to
eliminate the DKK then TXT sequence because you don't know the
capabilities of the verifiers. Can they fetch DKK? No one knows.

During transition, signers will be significantly at risk of not being
verifiable if they just use q=dkk. Hence, most, if not all signers
will likely use q=dkk,txt (or whatever the syntax is) to explicity
tell the verifiers to try both, which in turn means the signer has to
maintain both.

The net result is that signers will all be saying try DKK and fall
back to TXT.

The only true advantage to being explicit with q= is that it lets
TXT-only sites optimize away the failed DKK lookup, but it adds no
value to signers supporting DKK.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Mar 2006 13:23:53 -0800

> capabilities of the verifiers. Can they fetch DKK? No one knows.

1.  signers MUST have a TXT and SHOULD have a new RR.

2.  signers using RR indicate this with q=<newRR>.

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.

The only risk is having a verifier that does not know whether their DNS client 
code can support the new RR.  Seems a trivial configuration option.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Thu, 30 Mar 2006 21:40:29 +0000

> 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.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Mar 2006 13:55:20 -0800

> sender may need to support both record types forever.

well, probably not forever.  only during the transition period and that's not 
likely to be longer than twenty years...

> or not and whether that should be considered.

I think that specialized RRs are better than generic TXTs, so we should try to 
use them.  However relying on their use immediately would be unduly risky, in my 
view.  So this hybrid approach includes them and uses them when possible, but 
does not put end-to-end support of them into the critical path.

d/
-- 

Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Mar 2006 16:30:31 -0800

> capabilities of the verifiers. Can they fetch DKK? No one knows.
There are (at least) two reasons that the verifier might not be able to
fetch DKK:

(1) Their DNS infrastructure doesn't allow them to fetch a DKK record.

(2) The verifier itself doesn't support DKK lookups.

There seem to be sharp disagreements on (1), whether this is a problem
with current products, and how much legacy infrastructure there might be
that does not support new RRs.  I don't have any data at all on this. 
Does anyone have, or know where we could get, hard facts on what
products and versions would have a problem with a new RR (e.g., BIND
version<x.xx, etc.)?  I have heard comments that some domains are
running very old versions of BIND, but I don't know which ones are
actually a problem.

(2) is much less of a problem; it is an incompatibility in the sense
that an old verifier wouldn't understand new signatures, but we're
running into several of those.  If the IETF DKIM specification says that
support for the DKK RR is a MUST implement for verifiers, it should be
safe for any signer that is using other aspects of the new specification
to use only the DKK RR (assuming the infrastructure issue above isn't an
obstacle).  I would argue that the specification should also require, or
at least strongly recommend, verifier support for TXT as well, due to
the deployed base of TXT keys and the desire for DKIM to be able to
verify signatures from older signers.

-Jim