ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP acceptance chart

2005-11-04 07:12:53
On Fri, 2005-11-04 at 10:20 +0000, Stephen Farrell wrote:
Doug,

Douglas Otis wrote:
Once DKIM considers how to handle cases where the signing-domain and  
email-address domains are frequently different, then opportunistic  
techniques like those found in SSH look better than some complex  array 
of DNS records.  In the odd case where a domain is being  phished, an 
assertion carried within the signed message can indicate  the required 
bindings based upon a class of keys.  These captured  requirements would 
then block all cases where the requisite bindings  where not found.  

So you want us to define a "deny service to everyone
else from this domain who doesn't have this key" field
which is included in a header, and then also have an
ssh like mode of operation where anyone (who can mess
with the headers) can introduce new keys? No thanks.
Not without it being a lot more worked out and
demonstrated-safe.

It is a wonderfully dangerous idea though but I think
I'd prefer doing it at a lower layer, maybe using
RFC 3514? :-)

SSH works in part because there's a human in the loop
when it matters. Such a situation doesn't arise here.

The reference to SSH was to indicate that an opportunistic approach
could be used in a similar fashion.  Where the signing-domain and email-
address domain are different, then spoofing related protections would
require the recipient to review and approve the details of the disparate
identifiers.

The inference to a class of keys was considering the problem that not
all keys are equally trusted, where the scope of a binding would not be
applicable across all key classes.  For example, a key may be classed as
"delegated" when beyond the intimate control of the domain.  This could
affect (narrow) the binding scope of identifiers that would apply for
this domain's class of delegated keys.  A concept lacking in SSP and
DKIM. 

See:
9. Binding Identifiers
http://www.sonic.net/~dougotis/id/draft-otis-mass-03.html#anchor9

The effect of a binding assertion could be the same as a policy
statement that the signing-domain and the email-address domain must
match (broad binding).  It would not be a specific-key, but a class of
key where there may be separate "policies" established.  As shown, for
delegated keys, the binding scope would be asserted within the key
itself.

SSP is worthless at providing spoofing protection in the majority of
cases.  However, the opportunistic approach could extend spoofing
protection universally.  Only in those cases where an institution
stipulates that they constrain the email-address to the individual, and
that they sign all of their messages with the same domain, would an
automated assertion be possible.  There would be no risk of tampering.

These broad binding assertions within matching signing-domain and email-
address domain could be gleaned on-the-fly.  This would entail far far
less overhead when compared to the SSP discovery process of walking up
label-trees for each and every email-address. :-P

-Doug
  


_______________________________________________
ietf-dkim mailing list
http://dkim.org