Subject: Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

From: Jeff Macdonald <[email-masked]>
Date: Fri, 1 Oct 2010 10:56:38 -0400

On Thu, Sep 30, 2010 at 9:19 PM, Douglas Otis <[email-masked]> wrote:
> Is there a safe way to shift DKIM signature compliance based upon the
>  From header field to that of the Sender header field?

We've avoided the Sender header because most folks are confused when
Outlook says "on behalf of". And not all MUAs display that anyway.

I do agree that DKIM signature compliance should no be based on From.
In fact it should be a new domain/sub-domain altogether.

-- 
Jeff Macdonald
Ayer, MA

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

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 1 Oct 2010 16:27:29 -0400

> In fact it should be a new domain/sub-domain altogether.

The fundamental problem with the current situation is that the
authenticated identity is not displayed and the displayed identity
is not authenticated.  Rather than create a pointer indirection
relationship between From and d=, which requires a secure binding
as well as introducing a provisioning headache, maybe the right
approach is to push on the former problem: encourage MUAs to
display d= information when it can be validated (either directly
by the MUA or by relying on trusted Authentication-Results headers
from the last hop MTA).

-Pete

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 01 Oct 2010 15:06:31 -0700

On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote:
> is not authenticated.

Forgive my pursuing it in this fashion, but I'd class that as a first 
derivative, rather than fundamental.  (But, then, first derivatives are important.)

Fundamental is that DKIM is not trying to authenticate the message and it is not 
trying to authenticate any identity such as From:

It is merely trying to affix a /separate/ identifier, with a claim that its 
being affixed is valid, but not that it relates to any other aspect of the 
message.  In other words, it is trying to identify message streams, rather than 
"validate" messages or authors.

The fact that DKIM uses underlying crypto algorithms keeps confusing people into 
wanting to use it the way OpenPGP or S/MIME are designed to be used.  Ain't 
gonna work.

d/
-- 

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Oct 2010 20:24:44 -0400

> "validate" messages or authors.

We get that Dave.

But the message 'stream' must originate from somewhere and there is an 
originating signature that starts the stream and as long as the 
binding is with the 5322.From, you can not separate the two as much as 
you wish you.

I hate repeating it so don't get made at me, but the ideal is not 
representing the reality.

If you wish to completely separate the "message author" then 4871bis 
must change the required 5322.From binding from MUST to SHOULD|MAY. 
Only then will you begin to get what you are looking for. Until then, 
you will always continue to have this thorn of the side of "confused 
people."

You can't have a strong technical requirement by nullify by "words." 
You must remove the technical requirement first.  IMO what has 
confused people is this dilemma - a technical requirement vs words 
that conflict with it.

I think it would be a mistake to break that technical required 
5322.bind and I personally believe ultimately, policy will prevail in 
some form or another.  Some policies will be relaxed or not declared 
at all for any signer to take over a stream, and some policies will 
like to have control over the stream interference by spoofers or 
unauthorized signers.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 4 Oct 2010 11:45:19 -0400

Dave CROCKER wrote:
>> authenticated identity is not displayed and the displayed identity is
>> not authenticated.
> 
> 
> Fundamental is that DKIM is not trying to authenticate the message
> and it is not trying to authenticate any identity such as From: 
> 
> It is merely trying to affix a /separate/ identifier, with a claim
> that its being affixed is valid, but not that it relates to any other
> aspect of the message.  In other words, it is trying to identify
> message streams, rather than "validate" messages or authors.   
>
> The fact that DKIM uses underlying crypto algorithms keeps confusing
> people into wanting to use it the way OpenPGP or S/MIME are designed
> to be used.  Ain't gonna work.  
> 
> d/

But DKIM does indeed bind an identifier (d=) to a message
cryptographically in a way that allows an MTA to use the
reputation of the owner of the (yes, separate) identifier 
when evaluating the spamminess of a message.  The d= domain
is the "authenticated identifier" to which I was referring.
ADSP and the related third-party extensions try to create
a binding between d= and From: but either break applications
such as MLMs or create a provisioning problem where domain
owners need to explicitly configure the third-parties that 
are allowed to sign their mail.  These mechanisms are motivated
by the fact that MUAs typically display the From: field and
users tend to give credence to the identifier in this field
when evaluating phishing messages.  My point is that, rather
than trying to authenticate this field with DKIM + ADSP, we
should be encouraging MUAs to display the d= value and let
the user independently evaluate the reputation of the signing
domain and decide whether or not it was appropriate for the
domain to sign mail with the given From: line.  I can trust
a message From: paypal.com but signed with d=mipassoc.org
not because paypal.com has somehow "authorized" mipassoc.org
but because I subscribe to the dkim mailing list and I know
the context in which the message is being delivered.  I would
similarly know that my friend Joe has a vanity domain but
uses google apps for his mail, and expect to see a d=gmail.com
DKIM signature on mails from him.  If this changes for some
reason, I might call Joe and ask him if he changed providers.
Even if the MUA doesn't display the d= domain directly, I
can imagine they might implement security tools similar in 
spirit to some of the CA validation extensions for browsers 
that are available to warn the user in case the CA of a given 
website changes countries (see
http://files.cloudprivacy.net/ssl-mitm.pdf).

-Pete