Subject: [ietf-dkim] Thoughts on latest SSP draft

From: Arvel Hathcock <[email-masked]>
Date: Wed, 25 Jul 2007 09:54:11 -0500

Hi all!

I believe that the algorithm specified in the latest SSP draft (section 
4.4) is the best compromise possible and that it will cover the largest 
percentage of use cases.  However, I agree it's not perfect.  Algorithm 
steps #4 and #5 are the problem as there is no definitive list of TLDs 
available and yet these steps call for the use of such.  As an 
implementor I'm worried about how I can comply with this part of the 
algorithm.  These steps suggest the use of a locally maintained or 
implementation specific TLD list.  But such lists would necessarily 
differ from one deployment or implementation to another leading to 
inconsistent application of SSP in the wild.  This worries me greatly.

I'd like us to at least consider the possibility of removing the steps 
associated with querying the immediate parent of the domain in question 
(steps #4 and #5).  Admittedly, this causes more administrative hassles 
for certain classes of senders but no solution to this question will be 
perfect in all cases.

I keep coming back to this:  some of the brightest people I've ever meet 
are members of this WG yet we are still grappling with this issue.  I 
think this points to the fact that maybe we can't solve this one and 
that we should accept that and move forward with an even simpler 
algorithm (by removing these two steps).

Anyway, I bow to the collective wisdom here of course but I'm hoping we 
can at least discuss this some.

Arvel

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jul 2007 12:12:04 -0700

On Jul 25, 2007, at 7:54 AM, Arvel Hathcock wrote:

> Hi all!
>
> I believe that the algorithm specified in the latest SSP draft  
> (section 4.4) is the best compromise possible and that it will  
> cover the largest percentage of use cases.  However, I agree it's  
> not perfect.  Algorithm steps #4 and #5 are the problem as there is  
> no definitive list of TLDs available and yet these steps call for  
> the use of such.  As an implementor I'm worried about how I can  
> comply with this part of the algorithm.  These steps suggest the  
> use of a locally maintained or implementation specific TLD list.   
> But such lists would necessarily differ from one deployment or  
> implementation to another leading to inconsistent application of  
> SSP in the wild.  This worries me greatly.
>
> I'd like us to at least consider the possibility of removing the  
> steps associated with querying the immediate parent of the domain  
> in question (steps #4 and #5).  Admittedly, this causes more  
> administrative hassles for certain classes of senders but no  
> solution to this question will be perfect in all cases.
>
> I keep coming back to this:  some of the brightest people I've ever  
> meet are members of this WG yet we are still grappling with this  
> issue.  I think this points to the fact that maybe we can't solve  
> this one and that we should accept that and move forward with an  
> even simpler algorithm (by removing these two steps).
>
> Anyway, I bow to the collective wisdom here of course but I'm  
> hoping we can at least discuss this some.

No organization is able to impose changes to SMTP without the general  
consent of those creating and using the protocol.  Nevertheless, to  
deal with an emergence of IPv6, cryptographic assurances offered by  
DKIM should prove helpful provided:

1) Common use of multiple signatures is avoided.

2) Per user signatures is avoided.

3) DKIM has an explicit single transaction means to associate SMTP  
clients with signing domains.

4) DKIM has an explicit single transaction means to associate  
originating email-address domains with signing domains.

(A common mechanism can deal with #3 and #4 and also deal with  
multiple originating domains.)

5) Email acceptance is predicated upon the originating email-address  
domain publishing an MX record or A record.

At this point in time, it should be rather rare for incoming SMTP  
servers to depended upon a AAAA record for locating their servers.   
The DKIM WG should push to have A or AAAA record discovery  
deprecated.  Deprecating address record discovery techniques will  
eventually simplify where policy needs to be published.  At some  
point in the future, not publishing an MX record for the originating  
domain might cause a message to be rejected.  Either publishing  
policy at every A or AAAA record is required, or domain transversal  
(even limited transversal) would be otherwise required.  Even limited  
domain transversal should be avoided.

Points #3 and #4 can be fulfilled by placing a hash label below the  
_ssp._domainkey record of the domain being associated.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt

A:
Query for either MX or A or perhaps ANY record at the originating  
domain in question.

B:
When no MX or A is discovered, the message is suspect.

C:
When signed by a third-party domain, query for a  
<hash>._ssp._domainkey at the originating domain.

D:
When the hashed SSP record is not found, the signing domain is not  
authorized.

E:
When not authorized or not signed, query for the _ssp._domainkey record.

F:
When no (non-hashed) SSP record is found, there is no policy for the  
domain.

G:
When there is a policy for the domain, and it is strict but the  
message is not signed by either an authorized or first-party domain,  
the message is suspect.

The use of explicit authorization is vital:

a) to handle possible replay abuse

b) to handle possible compromised keys

c) to avoid administrative complexities

-Doug