Subject: [ietf-dkim] Doublefrom language should be in ADSP, not core

From: Michael Deutschmann <[email-masked]>
Date: Sat, 9 Jul 2011 16:19:17 -0700 (PDT)

One additional thought on the whole double-From: argument -- if RFC
language on the issue is justified at all, it really belongs in the
ADSP RFC, not a core DKIM one.

A double-From: doesn't even rise to the level of theoretical threat
except when dealing with ADSP (or a successor).

If we, for example, invented an "LDSP" protocol to allow mipassoc.org to
assert that any message bearing "List-Id: [email-masked]"
without a d=mipassoc.org signature is highly suspicious, then the
operation of that defense would be entirely unexploitable by
double-Froms.

Of course, a lazy "LDSP" might be exploited with multiple List-Id:
headers, and that would actually be more significant.  List-Id: was
invented after RFC822, so we can't claim multiple copies of it violate
the protocol.

To the core DKIM spec, "From:" isn't magic at all.  Rather than
enumerate every header that might be sensitive, we should put in a
non-normative note that layered protocols should consider the issue:

{
Most expected applications of DKIM will involve signatures added by a
sender in order to justify their use of a name in some other header of
the message.  For example, ADSP allows a domain to assert that
their signature must be present for a message bearing one of their
addresses in the From: header.

It is suggested that such layered protocols include an explicit
requirement to check for multiple copies of whichever header they
defend.  Otherwise, a situation could arise where a lazy validator
approves a message based on all appropriate signatures being present for
just one instance of the header, and yet a downstream entity falsely
assumes a different instance was so validated.
}

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 Jul 2011 03:22:01 -0400

> except when dealing with ADSP (or a successor).

-1, we didn't need ADSP to show it was a empirical problem here. 
Remember the President Obama message?

Now of course, if ADSP was a standard and whitehouse.com had an 
exclusive signing policy, receivers would of rejected the junk 
distributed by Dave's list server as an ADSP violation.  But ADSP is a 
pipe dream.

> non-normative note that layered protocols should consider the issue:

Not sure what that means - the 5322.From is the single most 
fundamental header in the email system.  DKIM could not change that 
and its why its a thorn on the side that its the one and only single 
requirement for binding.  At a minimum, a signature much has h=from.

This WG group has long suffered on the idea that From was a required 
bind and the 3rd party trust advocates have tried to minimize that and 
simple couldn't without proper logic.

The From signing requirement was based on the original framework when 
POLICY was a natural part of the algorithm - the security aspects of 
the protocol BROKE down when it was separated and we never got over it.

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

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 10 Jul 2011 00:53:14 -0700 (PDT)

> distributed by Dave's list server as an ADSP violation.  But ADSP is a

The attack only matters if the user believes that forgery is impossible
because his ISP and the putative sender both "deploy ADSP" -- and thus the
fact that the message made it to his mailbox means it has to be validly
signed.  (Of course, such users are suckers for messages from "0bama"...)

Otherwise, "Obama" messages with an alternate From: (which the forger
hopes the MUA will ignore) and signature for that second From:, are no
more convincing than plain old forgeries with a single From: and no
signature at all.  In fact, they can be less effective, since:

1. At any step on the way, the message may be rejected as a protocol
violation.

2. The MUA might display to the user, the From: instance that was
intended by the forger for the validator's eyes only.

3. The lazy validator might act on the From: instance that was intended
by the forger for the MUA to display.

Failures (from the forger's perspective) 1 and 2 produce a result less
convincing than a simple unsigned forgery.  Failure 3 produces a result
no more convincing than the simple unsigned forgery.

---

From: "McDowell, Brett" <[email-masked]>
Date: Sun, 10 Jul 2011 04:15:25 -0600

-1

---
Sent from my mobile phone

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 Jul 2011 07:22:50 -0400

Well, you have a point:

    DKIM has failed to address legacy spoofing problems.

The hope was this would be one of the highest and immediate benefits 
when an domain raised the bar by what was expected in his mail and 
supportive receivers saw deviations from the domain's published policy 
expectation.

But DKIM lost its reason for living when it failed to compete with SPF 
and SPF did this work of addressing legacy spoofs.   So DKIM looked to 
see if it can fill in the SPF hole with transition points (relays, 
multi-hops), thus offering an alternative for a path independent solution.

But before you can make DKIM work at any level, you can't do it on a 
relaxed principle that FAILURES is a norm or that anyone in the middle 
can break/resign the mail.

So as you stated, legacy mail still can exist because we don't know 
how to deal with failure or what is too be expected.

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 10 Jul 2011 05:24:18 -0700 (PDT)

>     DKIM has failed to address legacy spoofing problems.

That's not quite the point I intended to make.

I consider it faintly possible that a situation could arise where a lazy
validation module embedded in an MTA always checked the last of multiple
Froms:, while an MUA always displayed the first From: -- or vice versa.

But I find it very unlikely that a validation module embedded in the MUA
itself would be vulnerable.  It might fail to notice double Froms:, but it
will validate the same one it shows the user.  So it will either sound the
alarm, or say "correctly signed" while ignoring the address the forger
wanted the user to see, showing his own domain instead.

Now, unless the MTA is *so confident* that a signature should have been
there that it *refuses to deliver* suspect mail, its validator doesn't
have an effect on the end-user.  And such confidence isn't likely without
use of a layered protocol, ADSP being the only one published yet.

Thus, if the user has no validator in his MUA, for now it's just as if DKIM
didn't exist.  Doublefrom can't buy the forger anything more.  If he does
have a validator in his MUA, then he is unlikely to be vulnerable.

(and that doesn't even consider all the fuss we've made here about this
angel on a pinhead...)

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Jul 2011 21:46:20 -0400

> except when dealing with ADSP (or a successor).

The abstract for RFC 4871 starts ...

 "DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transfer Agents (MTAs) or Mail
   User Agents (MUAs).  The ultimate goal of this framework is to permit
   a signing domain to assert responsibility for a message, thus
   protecting message signer identity and the integrity of the messages
   they convey  ..."

Verification of source and contents is fundamental to the DKIM requirements.  
If it's not, the assertion of responsibility is meaningless (maintaining the 
assertion of responsiblity even though the message has been modified in a 
meaningful way is nonsense).  

I wish we could have removed l= for this reason.

I think we should make it clear that singleton header fields like From (and 
Subject and Date) can be added without breaking signatures unless one is 
careful as a signer and/or a verifier.  This is related to a core DKIM design 
principle and doesn't need ADSP (or other non-standard measures) for it to be 
something we should care about.

I haven't had time to carefully parse all the proposed language, so I'm not 
going to comment on the specifics of the current proposals, but I think it's 
just flat out wrong to claim that payload integrity is unrelated to DKIM.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jul 2011 19:48:43 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Deutschmann
> Sent: Sunday, July 10, 2011 12:53 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
> 

I think the attack only matters if the MUA believes that the only thing ever present in the inbox is a validly-formed message, *and* the presence of a DKIM signature (regardless of signing domain) means the message is somehow more valid than one without.

> signature at all.

+1

> In fact, they can be less effective, since:
> 

Right, or have the extra From: arbitrarily removed.

> no more convincing than the simple unsigned forgery.

+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jul 2011 19:51:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Sunday, July 10, 2011 6:46 PM
> To: [email-masked]

I think the language we've proposed in response to the DISCUSS covers this appropriately.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Jul 2011 07:49:16 -0700

+1

d/
-- 

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

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Jul 2011 10:30:57 -0700

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions