Subject: Re: [ietf-dkim] Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Jun 2011 10:33:12 -0700

On 6/23/11 8:24 AM, John Levine wrote:
> In article<[email-masked]>  you write:
>> On 6/22/11 11:14 AM, Dave CROCKER wrote:
>>> Folks,
>>>
>>> The bottom line about Doug's note is that the working group extensively
>>> considered the basic issue of multiple From: header fields and Doug is
>>> raising nothing new about the topic.
> Dave is quite right.  Doug's purported attack just describes one of
> the endless ways that a string of bytes could be not quite a valid
> 5322 message, which might display in some mail programs in ways that
> some people might consider misleading.  If it's a problem at all, it's
> not a DKIM problem.
Perhaps you can explain why the motivation stated in RFC4686 includes 
anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the 
 From header field MUST be signed?  Why RFC5617 describes the From 
header field as the Author Author address that is positively confirmed 
simply with a Valid DKIM signature result?  Both RFC4686 and RFC5617 
overlooked a rather obvious threat clearly demonstrated by Hector Santos 
on the DKIM mailing list:  Pre-pended singleton header fields.

Neither SMTP nor DKIM check for an invalid number of singleton header 
fields. These few header fields are limited to one because they are 
commonly displayed.  Multiple occurrence of any of these headers is 
likely deceptive, especially in DKIM's case.  DKIM always selects header 
fields from the bottom-up, but most sorting and displaying functions go 
top-down selection.

Complaints from John, Dave, and Barry and others is likely and 
understandably out of fatigue.  They just want the process to be over.  
We are now hearing there is a vital protocol layering principle at stake 
which even precludes DKIM from making these checks!  Really?

Although DKIM will be securely hashing the headers fields which MUST 
include the From header,  developers are being told they must ignore 
multiple singleton header fields discovered in the process.  It is not 
their burden!  As if securely hashing, fetching any number of public 
keys, and verifying any number of signatures isn't?

-Doug

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

---

From: Al Iverson <[email-masked]>
Date: Fri, 24 Jun 2011 12:47:10 -0500

On Fri, Jun 24, 2011 at 12:33 PM, Douglas Otis <[email-masked]> wrote:
> anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the From
> header field MUST be signed?  Why RFC5617 describes the From header field as
> the Author Author address that is positively confirmed simply with a Valid
> DKIM signature result?  Both RFC4686 and RFC5617 overlooked a rather obvious
> threat clearly demonstrated by Hector Santos on the DKIM mailing list:
>  Pre-pended singleton header fields.
>
> fields. These few header fields are limited to one because they are commonly
> displayed.  Multiple occurrence of any of these headers is likely deceptive,
> especially in DKIM's case.  DKIM always selects header fields from the
> bottom-up, but most sorting and displaying functions go top-down selection.
>
> understandably out of fatigue.  They just want the process to be over.  We
> are now hearing there is a vital protocol layering principle at stake which
> even precludes DKIM from making these checks!  Really?

I'm not suffering from fatigue, personally, and I agree with their
negative reaction toward your commentary. You're speaking as though
you expect DKIM to be the *only* type of message validation that's
going to happen to a message and thus it must account for and handle
message flaws far outside of scope.

This is like complaining that four wheels don't work as a car. True,
but you're missing the point. And you're doing it in a manner so laden
with hyperbole as to be offensive. It's really distressing and
disrespecting to the rest of us to have to read your same complaint
over and over and over. You've made your point. Few (none?) seem to
agree. Could you please move on?

Regards,
Al Iverson

---

From: Steve Atkins <[email-masked]>
Date: Fri, 24 Jun 2011 14:43:27 -0700

> which even precludes DKIM from making these checks!  Really?

While people are tired of you, fatigue is not the issue.

Rather it's that you either don't appear to accept the fact that very few people agree with you, rather you continue to bring up exactly the same issues repeatedly, even though you know you're not going to convince anyone by that repetition, as they've explained to you in detail, repeatedly why your concerns are unfounded. That ends up consuming many peoples time to no good result.

Your current argument is of the form:

    Doug: X is bad, and could theoretically lead to end-user confusion in one particular obscure replay scenario, given a carefully chosen set of assumptions about MUA user interface design.

    World: Yes, X is bad, but it's out of scope for the DKIM protocol, as it's nothing to do with DKIM, rather it's a violation of 5322. 

    World: Spam filters and MTAs should certainly consider it, though. 

    World: Heck, DKIM *implementations* probably should, even though it's not part of the DKIM protocol - other than "DKIM applies to email, and data streams with X are not email".

    Doug: If it's not in the DKIM protocol, then "we" are telling the entire world that they MUST NOT pay attention to X anywhere in their mail handling process...

    World: Uhm... what? No, we're not. That's just rid....

    Doug: .... and that makes DKIM worthless!

    World: Uhm... what? No, that's not what we said.

Repeat, ad- nauseam and beyond.

(Attempting to drum up support in other fora after you've failed to get it here, presumably in the hopes of gaining supporters who'll come here to continue the good fight seems unlikely to benefit anyone involved, either.)

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Jun 2011 16:04:59 -0700

> Repeat, ad- nauseam and beyond.
Steve and Dave,

Allow me to bring up a few new (albeit related) issues then.

ADSP (RFC5617) depends upon DKIM's output.  ADSP failed to consider a 
pre-pended header threat.  When present, this unchecked threat means the 
Author Address is undefined.  Those trusting ADSP results are placed at 
risk due to a lack of assurance pre-pended header fields were excluded.

Message Header Field for Indicating Message Authentication Status 
(RFC5451) also depends upon DKIM's output.  This specification also 
failed to consider a pre-pended header threat.  When present, this 
specification lacks signaling to indicate whether signed singleton 
header field replicates were excluded and of course the header.from is 
undefined.  Those trusting an Authentication-Results header field are 
placed at risk due to the lack of assurances that pre-pended header 
fields were excluded.

Does this avoid the "out-of-scope" claim being repeated ad-nauseam?

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Fri, 24 Jun 2011 16:46:48 -0700

> risk due to a lack of assurance pre-pended header fields were excluded.

I think this is just a restatement of your previous concern, rather than a
new issue. It seems out of scope for this thread, though, as this thread
is discussing DKIM, while you're talking about an ADSP issue.

Perhaps bringing it up in it's own thread (with ADSP in the subject
line) would let people who are interested in the ADSP specific aspects
pay attention to them.

> placed at risk due to the lack of assurances that pre-pended header 

This is just a restatement of your previous concern, it is not a new
issue.

Cheers,
  Steve

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Jun 2011 22:07:47 -0400

One final response from me to this, because it is relevant to the IETF
last call:

> understandably out of fatigue.  They just want the process to be over.

No.  We want to get the spec right, and to make sure it specifies the
right normative things.

> Although DKIM will be securely hashing the headers fields which MUST include
> the From header,  developers are being told they must ignore multiple
> singleton header fields discovered in the process.

No one is saying that anyone "must ignore" anything.  If you think we
are, cite the words in the spec that say that.

What we are saying, and have said repeatedly in many places, is that
it is not the job of the DKIM specification to define the handling of
this normatively.  Developers may certainly handle the presence of
multiple instances of header fields that are not allowed to have
multiple instances... in any manner they like, and we even suggest
(non-normatively) what they might do -- and ignoring the situation
isn't among our suggestions.

But it's not a normative part of the DKIM protocol, and it shouldn't be.

Now I'm done responding to this topic.  The points have all been made,
on both sides.

Barry, DKIM chair

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2011 10:45:29 +0100

On Fri, 24 Jun 2011 22:43:27 +0100, Steve Atkins <[email-masked]>  
wrote:

>     Doug: X is bad, and could theoretically lead to end-user confusion  
> in one particular obscure replay scenario, given a carefully chosen set  
> of assumptions about MUA user interface design.

That scenario may well be particularly obscure at the present time. But as  
soon as the Bad Guys cotton on to the possibility, you may be sure that it  
will become as common as mud.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 28 Jun 2011 15:07:19 +0200

One final note from me, as I want to state my current position regarding 
4871bis, with respect to Last Call.

As the receiving verifier has all the information to _reliably_ [0] 
determine which combination(s) [1] of From [2] and DKIM-Signature 
verifies correctly, it has the means to provide any consuming 
application with the right information. The mechanism(s) by which the 
verification results can be communicated to a consumer (as per par. 6.2 
of 4871bis) can be chosen by the verifier and does not restrict the 
results to only TEMPFAIL, PERMFAIL and SUCCESS [3].

Second, today there is hardly any installed base of MUA's that present 
any form of DKIM results to the end user, so most of this technology 
still needs to be written and 4871bis contains sufficient warnings about 
duplicate From and other fields; so in my view the argument of DKIM not 
being 'compatible' with the currently installed base of MUA's does not 
apply.

Third, DKIM is only one of multiple technologies that can and will be 
deployed by both senders and receivers. This means that any policy 
published by a sender regarding the use of DKIM does not have to provide 
a sharp 'black' or 'white', 'keep' or 'discard' result. Senders that 
wish to publish a policy need to take into account that the world is not 
perfect and that there always will be lousy implementations of protocols 
(be it RFC5321, RFC5322, RFC4871 or RFC4871bis). [4] It's better to 
acknowledge this, than to rely on the 'MUST's in this particular DKIM 
RFC. Policies that do not take this into account, can/may have dramatic 
results.

Hence, I no longer see a problem in 4871bis not mandating the duplicate 
header check.

/rolf

[0] irrespective of whether a From field has been prepended or appended 
or no such thing at all
[1] (s) plural form, if there are multiple DKIM-Signatures and multiple 
 From fields.
[2] From is mentioned here only:
- because it is the only mandatory header field to be used to generate 
the signature and
- for the case that there's a consuming application that would display 
the From header, which in your view is the attack vector
Apart from that, there is no special reason to focus here on From
[3] although TEMPFAIL and PERMFAIL are mentioned in 4871, there is no 
equivalent identifier for a positive result, is there? I suggest to make 
the success status explicit in 4871bis
[4] The fact that a sender doesn't know in advance how well the receiver 
implements the DKIM verification process will need to be taken into 
account for any policy protocol that will be built on top of DKIM.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html