Re: [ietf-dkim] Role of Sender header as signing domain

[Douglas Otis <[e-mail]>]

On Nov 28, 2006, at 4:48 AM, Charles Lindsey wrote:

> On Mon, 27 Nov 2006 13:07:02 -0000, Stephen Farrell  
> <[e-mail]> wrote:
>
>> Charles Lindsey wrote:
>>> On Sat, 25 Nov 2006 06:25:27 -0000, Jim Fenton <[e-mail]>  
>>> wrote:
>>>
>>>> It's not entirely forgotten; section 2.3 of draft-allman-dkim- 
>>>> ssp-02 discusses multiple From addresses.  We thought about  
>>>> resolving the ambiguity by (1) arbitrarily picking the first  
>>>> address in the From header field, (2) picking the address in the  
>>>> Sender header field, or (3) querying SSP for all addresses in  
>>>> the From header field, and combining them somehow.  We picked  
>>>> (1), ...
>>>
>>>  And there I think you picked the wrong one.
>>
>> Fair enough that you disagree, but the main point though is that  
>> the WG reached rough consensus.
>>
>>> I have seen sufficient comments from others to the effect that  
>>> the Sender needs to be looked at in many situations that this  
>>> matter probably ought to be reviewed (does that mean raising an  
>>> Issue?).
>>
>> No. For base, Barry and I are using a scheme where re-opening a  
>> decided issue (which is what you'd presumably like in this case)  
>> requires N people supporting, for some informally defined, but  
>> increasing, value of N ....
>
> That is fair comment, but there seem to be an awful lot of people  
> still discussing the Role of Sender (and even List-ID and Return- 
> Path) as possible signing domains.
>
> OK, this is a petition for reopening this Issue. That gives 1 vote,  
> but you will need lots more to take action. So I invite anyone else  
> who supports this view to reply with a +1. If there is insufficient  
> support, then I will shut up.
+1!

Selection of the From address is premised upon a bad assumption that  
by only "authorizing" this header, spoofing an "author" of the  
message can be prevented.  This concept remains highly flawed for the  
following reasons:

1) Only the display name may be visible.
2) The display name may appear as the actual email-address.
3) UTF-8 support makes human checking impossible.
4) Look-alike and cousin domains are not prevented.
5) Increases likelihood of multiple From email-address use.
6) Not likely able to incorporate EAI email-address versions.
7) Establishes credibility of phishing attempts by self "authorization".
8) Reduces email delivery integrity in many scenarios.
9) Requires excessive DNS overhead climbing label trees for every
      unsigned message to satisfy a small percentage of domains that
      will publish an "all From headers should be signed."

This narrow view overlooks a far more protective alternative that:
1) Thwarts look-alike and cousin domains  spoofing.
2) Is compatible with any EAI scheme.
3) Will not increase credibility of phishing attempts.
4) Will increase email delivery integrity.
5) Will not require excessive DNS overhead.
6) Can be implemented by the recipient and email-address domain
      owner independent of their providers.
7) Eliminates exchange of private keys with providers, zone
      delegations to the provider, or negotiations with the provider the
      selector locations for a series of CNAME records.

The alternative is protection by an annotation scheme checking two  
basic items:

1) Is a signed email-address known by the recipient (i.e. in the  
address-book)?

2) Is the signing domain designated by this email-address domain?
     (Obvious only when same domain.)

When other headers are used to communicate with a recipient, then  
which headers gets annotated can still be controlled by the domain of  
the email-address ONLY when other headers are allowed to make  
associations!

Setting flags regarding whether all such headers are signed can be  
added.  However, such flags should not be checked by most  
recipients.  A false expectation of blocking abuse by way of  
"authorization" has been shown not to work, but this seems to be what  
is behind most participants motivations.  This limits their thinking  
to only the use of the From header.  Allowing associations to support  
an annotation scheme has not been considered.  The same association  
scheme can also prevent white-listing abuse and ensure DSNs once this  
approach is considered more carefully.

-Doug




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