[ietf-dkim] Blocking/Restritive-Policy vs Annotation/Associative-Policy

[Douglas Otis]

On Dec 8, 2006, at 4:22 PM, Hector Santos wrote:
> Douglas Otis wrote:
>> On Dec 8, 2006, at 3:05 PM, Hector Santos wrote:
>>>
>>> Nope, once again, MUA are not required. I can do the above easily  
>>> at the MDA.
>>
>> Is viewing the display name protected by this effort?
>
> N/A - MUA are not part of the process for this protocol ratification!

What element is ratified?  What benefit is established when  
recipients may not understand what is signed, and who actually sent  
the message?  Do you care this blocking scheme fails to ensure  
recipient protections?  This should not be just a check mark on a  
feature list.

>> Is receiving non-ASCII email-addresses protected by this effort?
>
> Unrelated to the basic QUESTION of DOMAIN protection via SSP.

Rather than just establishing restrictions, policy can also establish  
associations and permit a "recognized" email-address 'X' to be used  
in conjunction with signing-domain 'Y' to generate an annotated  
message.  Annotation can be a gold-star or placement into a folder or  
specialized mailbox handled by _either_ the MDA or the MUA.    
Recognition criteria can be established by the account's address-book  
or a DAC list.

>> Are look-alike and cousin-domains prevented?
>
> Doesn't APPLY!

What is the goal then?

>> What happens when a domain wishes to allow users use of a mailing- 
>> list?
>
> Then the domain asking for trouble because MAILING-LIST are know to  
> break the integrity of the mail.

When a message is signed by a mailing-list, this establishes their  
signatures integrity.  Annotation can make it clear the header used,  
and that the originator is known (and trusted).  When annotation  
added by the MUA or MDA _is_ the protective mechanism, use of a  
mailing-list is never a problem and nothing is broken.  A mailing- 
list only becomes a problem when subjected to a highly flawed  
blocking scheme unable to provide adequate protection anyway.

>> Should they setup different domain names, or use a sub-domain?
>
> Maybe, if that is what they want.

This then increases recipient's confusion about what is being checked  
with a blocking scheme.

>> How will increased domain names of the same entity better allow a  
>> recipient to detect a spoof?
>
> Doesn't apply. We are talking about 1 domain.  One transaction at a  
> time.

This is about protecting recipients from being spoofed.  This is not  
about making sure a message jumps through a set of hoops.

>> You can not offer "pretty good protection" at the MTA based upon  
>> policy blocking.
>
> I sure can and if I didn't think so, I wouldn't be touching or even  
> looking at DKIM/SSP.

It is hard to understand your goals.  What constitutes "pretty good"  
when recipients can still be spoofed?

>> Simple schemes remain where your customers continue to be spoofed.
>
> Not with a DKIM/SSP framework.  Phished? sure. not SPOOFED.

Huh?

> Plus if a bad guy wanted to BREAK DKIM/SSP, all he has to do is  
> AVOID using it and stay away from DKIM/SSP protected domains!

Bad actors would only need to provide the appearance of being from  
the trusted domain.  This is easily done with the proper HTML format  
and images.  It is also common to see display-names that make it  
appear the email-address is being displayed, when it is not.  The  
visual tricks are vast.

>>  Annotation at the MUA can prevent these schemes,
>
> This is like saying,
>
>    "Mom, can I let the rabid dog in the house? He looks so cute!"
>
> Mom is not going to let johnny get in trouble if she can help it.  
> But just in case, she might give Johnny a rabbies shot.

Not really.  Annotation offers a clear indication about which dogs  
are known safe.  Your scheme lets in any dog and offers no clue which  
are safe.  Don't expect Johnny to look at the dog's tattoo under  
their lip.

>> works with non-ASCII email-addresses, prevents look-alike and  
>> cousin domains exploits, and permits the use of mailing-lists  
>> without additional domain names.
>
> Out of scope!  You're stuck with this because you are looking for a  
> MUA solution - unrealistic.

This approach can be applied at _both_ the MDA and MUA.  Message  
annotation has a realistic chance of offering real protection.  A  
blocking scheme does not!

>> Policy based blocking is not a desirable feature when it will  
>> likely make the situation worse at substantial costs to resources.
>
> But that premise is highly false.

DNS transactions required to discover whether policy is within any  
domain level for any message, signed or not, is not trivial  
overhead.  In addition, there will be support calls dealing with  
messages lost by various services.  There will be issues created when  
the use of EAI extensions is prevented.  There is information leaked  
to bad actors regarding the level of acceptance achieved at the MTA.   
There are still problems related to white-listing and the properly  
handling of DSNs not improved by a blocking strategy.  Comparisons  
between blocking and annotation are rather stark in terms of costs  
and benefits.

-Doug