Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt

From: [email-masked]
Date: Tue, 12 Apr 2011 14:45:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title           : DomainKeys Identified Mail (DKIM) Signatures
	Author(s)       : D. Crocker, et al.
	Filename        : draft-ietf-dkim-rfc4871bis-06.txt
	Pages           : 76
	Date            : 2011-04-12

DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the
message.  This can be an author's organization, an operational relay
or one of their agents.  DKIM separates the question of the identity
of the signer of the message from the purported author of the
message.  Assertion of responsibility is validated through a
cryptographic signature and querying the signer's domain directly to
retrieve the appropriate public key.  Message transit from author to
recipient is through relays that typically make no substantive change
to the message content and thus preserve the DKIM signature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Apr 2011 17:05:02 -0700

http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8
,---
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322 
<http://tools.ietf.org/html/rfc5322>], [RFC2045 
<http://tools.ietf.org/html/rfc2045>], and
any other relevant message format standards. See Section 8.15 
<http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15> for
additional discussion and references.
'---

Should change to:
---
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322 
<http://tools.ietf.org/html/rfc5322>], [RFC2045 
<http://tools.ietf.org/html/rfc2045>], and
any other relevant message format standards. See Section 8.15 
<http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15> for
additional discussion and references.  In addition, verifiers MUST
ensure the presence of multiple singleton originating header fields
do not provide a valid signature result.
---

Not including this additional requirement removes recipient assurances a 
sender may have expected to be offered by DKIM.  Without this additional 
requirement, confidence in DKIM can be lost when injected From headers 
are both displayed and used to make incorrect folder placements.  ADSP 
or ISP imposed acceptance criteria for likely phished originators can be 
easily foiled by this tactic upon which a recipient may depend.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 15 Apr 2011 22:27:04 -0400

> any other relevant message format standards.

Hey, could you talk to the guy who just proposed putting UTF-8 selectors 
and domain names into the signature headers and explain to him why that's 
a bad idea?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 15 Apr 2011 20:59:48 -0700 (PDT)

On Fri, 15 Apr 2011, Douglas Otis wrote:
> In addition, verifiers MUST
> sender may have expected to be offered by DKIM.

Not... This... Again...

There are already other ways to get a phish past an unsuspicious user in
spite of DKIM/ADSP.  The full name trick is one, mi5pe11ings are another.
Also rather important is that few users are likely to have the thing armed
to block mail.

You're basically trying to weatherstrip a barn door that we have no idea
how to even close.  Pointless.

(Also, the extra filtering you want would quickly be added to
SpamAssassin anyway, once people try to exploit it.)

Requirements to strictly enforce the message format do have a place, but
in a different RFC.  Such an RFC would outline minimal standards for
supression of forgeries.  Email providers who follow this hypothetical
RFC would advertise that fact, and then phish-target sites might reward
users who provide a contact address at a compliant site.

But you'd need to put a lot more than just a reference to ADSP and your
enforcement of a unique From:, to make such a document viable.

Otherwise phish-targets won't offer sufficient reward to be worth the
tech-support hassle of being unable to disable ADSP (lest they lose
compliance) at the request of a user with a false-positive problem.

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

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Apr 2011 11:23:31 -0400

> sender may have expected to be offered by DKIM.

Yes; we discussed this to death and consensus was against saying that.
 Your objection to the consensus is noted; nevertheless, we do have
rough consensus.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Apr 2011 15:29:01 -0700

> how to even close.  Pointless.
Michael and Barry,

For the record...

One method to avoid look-alike or display-name attacks would be to sort 
messages into folders.  A fairly common practice.

On the basis of message sorting, specific From domains accepted on the 
basis of Author-Domain DKIM signatures would provide significant 
protection not easily thwarted.  However, failings to include multiple 
 From header field checks during signature validation would permit 
simplistic phishing attacks not controllable by the domain being 
phished.  :^(
> users who provide a contact address at a compliant site.
Trust in DKIM would be misplaced when negligent verification processes 
lack both obvious and simplistic checks representing a tiny fraction of 
a signature verification process.  When the concern is about resource 
consumption, having SPAM filters recheck for multiple origination 
headers because essential checks were specified as SHOULD rather than 
MUST only adds to this level of waste.
> compliance) at the request of a user with a false-positive problem.
DKIM is about enabling protective policy based upon valid signatures 
without requiring modifications to MUAs.  It should not matter whether 
the policy is being applied by the enterprise on behalf of employees, or 
by ISPs on behalf of their users.  Do not permit such an obviously 
defective verification process to be specified.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 19 Apr 2011 20:55:45 +0100

> do not provide a valid signature result.

Yes indeed. We discussed lots of wording for all of this, and the one that  
has got into the document is about the worst.

It is Absolutely Pointless to check for minor infringements of 5233 et al,  
and so to say that implementors SHOULD check for some "reasonable" subset  
of infringements is ridiculous, unless you spell out what "reasonable"  
really implies. Now AFAICS, minor infringements in the format of  
particular headers etc, "naughty" as they might be, have no impact on  
DKIM. The "naughtiness" will be signed, so you can see whether it was  
present at signature time, if you happen to care about it.

But there is just ONE breach of 5322 (so far as we know) that is serious  
enough to break DKIM completely. And that is repeated headers that should  
not be repeated. A number of scams involving repeated From headers have  
been described, and one can well imagine there may be scams with repeating  
Subject, Content-Type, Message-ID and whatever else (and if you are going  
to catch one, then catching the others with the same code has negligible  
additional cost).

So if we are going to have normative language (such as SHOULD or MUST),  
then let us address it to the known problem, rather than to some vague  
"reasonable" test that might lead people to waste time on things that are  
not broken, and omit the one case that is broken.

Moreover, when it comes to a choice between SHOULD and MUST, the narrower  
the test you are asking for, the easier it is to justify a MUST wording.

So there are just two questions to ask:

1. What exactly do we really REALLY want implementors to do in this  
matter.?

2. Is it to be a SHOULD or a MUST?

Note that I have escalated this to as Issue. DKIM is broken if we do not  
get this right.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Tue, 19 Apr 2011 20:58:33 +0100

>  Your objection to the consensus is noted; nevertheless, we do have

Not really. There was so much misunderstanding of the problem, and so many  
texts proposed, that it is entirely unclear as to exactly what the final  
consensus was. For sure, the wording that finally arrived is about as  
unhelpful to the implementor as it could be.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Apr 2011 14:37:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Tuesday, April 19, 2011 12:56 PM
> To: DKIM
> Subject: [ietf-dkim] Issue: Repeated headers
> 

Where is your proposed alternate text?  Complaining without it isn't especially helpful during a WGLC.

> present at signature time, if you happen to care about it.

I believe the added text adequately addresses this problem, especially the new Section 8.15.  I also believe that the chair has said we have rough consensus on this point.

> not broken, and omit the one case that is broken.

We do have normative language, in 3.8.  And the text in 8.15 makes it clear what the attack is, and therefore what the "reasonable" defenses are.

> 1. What exactly do we really REALLY want implementors to do in this

I believe Sections 3.8 and 8.15 make this clear to anyone that's designing and implementing software in this area.

> 2. Is it to be a SHOULD or a MUST?

Given the RFC2119 definition, I think we've appropriately settled on SHOULD.

I don't want to re-hash all the arguments.  What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Apr 2011 14:48:02 -0700

> Where is your proposed alternate text?  Complaining without it isn't especially helpful during a WGLC.
Here is mine. :^)

http://mipassoc.org/pipermail/ietf-dkim/2011q2/015838.html

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 19 Apr 2011 18:55:04 -0400

> I don't want to re-hash all the arguments.  What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer.

I agree that the current language addresses the issue about as well as it 
could be addressed, and see no advantage in rearguing it.

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 19 Apr 2011 16:29:23 -0700

> could be addressed, and see no advantage in rearguing it.

+1

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Apr 2011 18:15:52 -0400

> has got into the document is about the worst.

Your objection is noted.

> Note that I have escalated this to as Issue. DKIM is broken if we do not

This is reopening a closed discussion, and the chair considers that
inappropriate and unwarranted at this stage.  It has been decided.  I
appreciate that you disagree with the decision, and that will be noted
in the PROTO writeup when I do it.

Barry, as chair

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 20 Apr 2011 22:25:54 -0700 (PDT)

> messages into folders.  A fairly common practice.

Users with the technical acumen to do such sorting are unlikely phish
victims.  They might not immediately recognize a message as forged, but
will instantly become suspicious if asked to "re-enter" passwords.

Once they detect such a phish, they may be annoyed, but they can then
implement a double-From: filter to drop future attempts on their own,
without needing an RFC to tell them so.

> simplistic phishing attacks not controllable by the domain being

Phishing attacks are *never* controllable by the domain being phished.
Nothing forces an ISP to deploy receiverside ADSP at all.

To change that, you need to invent some sort of certification for ISPs
that they take reasonable steps to prevent forgery.  Then banks could
impose a "phishing insurance" surcharge on any user who provides a contact
address at a domain that is not certified.

An explicit requirement to reject double-froms would be appropriate in
the standards for such a certification, but not in the draft at issue.

---

From: Hector Santos <[email-masked]>
Date: Fri, 22 Apr 2011 13:56:28 -0400

Michael Deutschmann wrote:

> impose a "phishing insurance" surcharge on any user who provides a
> contact address at a domain that is not certified.

My opinion (of course).

So presuming there is a discovery method lets say for ISP/ESP domains 
with ADSP Checking Support, gmail.com users will have a bank surcharge 
and hotmail.com will not?

Personally, I think a bank imposing a surcharge has legal issues, like 
anti-trust, so its probably be more of an Bank TOS where

  - Bank requires ADSP checking ready hosting domains,

  - Bank requires hosting domains checking for the bank's
    AUID authorized SDID, either as a AUID/SDID combination
    or possibly via VBR, ATPS, ASL.

  - Bank offering their own 1st party email hosting service.

It will depend on what authorized signer (SDID) the bank will select. 
  If its a 1st party signature (AUID==SDID) then POLICY support 
discovery is needed.  If a 3rd party signature is used (AUID!=SDID), 
then now we move into the bank discovering what hosting domains will 
authorized the specific 3rd party AUID!=SDID condition.  IMO, for an 
external SDID vendor, the bank may have a concern relying on hosting 
domain trusting all messages signed solely based on the same SDID.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Apr 2011 11:45:50 +0100

> in the PROTO writeup when I do it.

There may be a rough consensus for the present text, but my understanding  
of the IETF procedures is that "rough consensus" is always trumped by Hard  
Technical Facts.

And I ASSERT that the following is a Hard Technical Fact:

    Where a Vewrifier is minimally compliant with the present draft,
    in particular if it omits any test for repeated headers (there is
    no REQUIREMENT for such a test), then a phisher can easily devise
    a message which, in the majority of current MUAs, will be displayed
    as "From: [email-masked]" and which will pass through that
    verifier unscathed. This is true whether or not paypal.co.uk has
    declared a Discardable ADSP policy and that Verifier implements ADSP.

I have described this attack several time on this List, and yet it still  
works. Hence the present draft can only be described as unfit-for-purpose.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Apr 2011 11:45:57 +0100

On Tue, 19 Apr 2011 22:37:59 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> From: [email-masked]  
>> [mailto:[email-masked]] On Behalf Of Charles Lindsey

Well the message I was replying to contained a wording from Doug. But here  
is my suggestion for 3.8:

3.8.  Input Requirements

    DKIM's design is predicated on valid input.  Therefore, signers and
    verifiers SHOULD (?MUST?) ensure that the messages they are processing
    are valid, at least to the extent that no header field occurs more than
    once where such is forbidden by [RFC5322], [RFC2045], or any other
    relevant message format standards.  See Sections 8.14 and 8.15 for
    additional discussion and references.

Essentially, that replaces "reasonable steps" by "at least <doing the  
duplicate header check>". It also adds a reference to 8.14.

> I believe the added text adequately addresses this problem, especially  
> the new Section 8.15.

There is much duplication and confusion between 8.14.and 8.15 (e.g. the  
technique of using "h= ... from:from: ..." is described in both, though it  
is only really applicable to 8,15. So here are some proposals:

8.14.  Attacks Involving Addition of Header Fields

2nd para, line 5 s/last/first/ (I think that was a typo).

3rd para (describing "h= ... from:from: ...")
At the end, add:
    However, this offers no protection if the attacker is also himself
    the signer.

Alternatively, delete that 3rd para (since it is duplicated in 8.15) and  
substitute:

    Note that the technique for using "h= ... from:from: ...", described
    in Section 8.15 below, is of no effect in the case of an attacker who
    is also himself the signer.

4th para line3 s/forgives malformations/forgives such malformations/

8.15.  Malformed Inputs

1st para line 3
    s/in a replay attack/in a replay attack or a man-in-the-middle attack/

2nd para line 3
    s/but in some cases it might display/it will commonly (?often) display/

3rd para line 1
    s/implementers are strongly advised to/implementrors need to/

3rd para line 3
    s/Section 3.6 of [RFC5322]/the relevant standards [RFC5322], [RFC2045],
    etc. (See Section 3.8)/
(for consistency with 3.8)

3rd para line 4: add "Reply-To:" and "Date:"g to the list of headers  
typically displayed (Date: is particular relevant for replay attacks).

> We do have normative language, in 3.8.  And the text in 8.15 makes it  
> clear what the attack is, and therefore what the "reasonable" defenses  
> are.

No, section 8.15 only deals with replay and man-in-the-middle attacks. The  
REAL problem is attacks by a phisher who provides perfectly valid  
signatures from his own throwaway domain.

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 25 Apr 2011 04:53:04 -0700 (PDT)

> and hotmail.com will not?

If Hotmail always respects dkim=discardable and Gmail ignores it, then
yes.

> It will depend on what authorized signer (SDID) the bank will select.
This paragraph was a little too jargon thick for me to process fully.

However, I suspect you're getting at the fact that, if it had to be
written today, such a certification standard would be hamstrung by the
fact that ADSP sucks.

All it could do is make dkim=discardable *binding*.  Since a bank that
wants the freedom to have their employees speak ex-cathedra on ordinary
mailing lists cannot use discardable, they would not be able to take
advantage of the phishing protection.

Obviously then, writing an improved ADSP-alike protocol is higher
priority than writing the certification standard.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 11:38:00 -0700

> Sent: Monday, April 25, 2011 3:46 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Issue: Repeated headers
> 

The chair has declared this particular topic closed, so I defer to him about this proposal.

My understanding (as a WG chair, though not of this WG) is that the presentation of working group consensus is presumed to have taken technical facts into account, so the assertion of a "Hard Technical Fact" does not automatically trump working group consensus.

Besides, there is no debate about what the attack is.  The issue is whether or not this is the right place to make normative assertions about how to deal with it.  The text we have now is a compromise between two hard-fought views of the answer to that question.  It is a path forward, and (as one of the antagonists of that debate) I think it quite reasonable.

> [...]

Those all look okay to me, and as they're largely editorial I'll include them in the next version unless someone objects.

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Apr 2011 18:07:53 -0400

> written today, such a certification standard would be hamstrung by the

Almost... see below.

> advantage of the phishing protection.

Its hard for me to imagine a bank's company DKIM email policy for 
employees will be not different than a Bank's vendor/user DKIM TOS 
(Terms of Service) requirement agreement.  So a bank who might begin 
to be concern about securing new vendor/user eBank communications (for 
PCI reasons) will probably begin to use different domains.

> priority than writing the certification standard.

Overall, I believe it all falls under some form of policy whether its 
an author domain policy or signer domain policy, even trust, 
certification or reputation policies.

So even when bank has a DKIM TOS requirement for bank/users 
transactions, the user host domain will need to be aware of the bank's 
DKIM TOS policy whether its ADSP-like and/or TRUST (rfc4871bis) based. 
  There has to be some form of prior end to end knowledge.

I can provide a perfect real life example of how email or user access 
evolved altering many features in a mail hosting system.

There are two forms of MUAs; online and offline.

Most systems started with online only and they came with strong 
message controls, for example, Message marked Read/Received and the 
ability to snoop or preview a message was a privilege feature for 
operators.

When offline MUAs became more important, now you had the roaming user 
design problems where the user working from home or work needed the 
ability to pick up mail from both machines and that required a "snoop" 
idea - not marking the mail received.  If the mail was marked received 
when he popped in from work, he would not be able to download the same 
mail from home.

Offering that feature for the growing offline MUAs became a problem 
for subscription services because now the hosting operators lost the 
ability to trace important mail receptions, such as Expiration 
Warnings, Service Notifications, etc.  Out of the box, our system has 
a 30, 15, 7 day Expiration Warning with billing details and if the 
user was able to "snoop" at these messages, they can claim they never 
got the warning.

So new tracking methods were needed to offers users to ability to 
preview mail, yet track reception needs for the backend.

For technology that attempts to time-shifted offline communications, 
the goal is to offer the same online access/security profiling 
requirements in an offline fashion.

How this applies to DKIM?

For the bank or anyone for that matter, if they only focus on online 
activity, the offline MUA needs are less important.  Mail is not 
accessible for POP3, NNTP.  You have to go online.  If it offered an 
IMAP or some Exchange Proxy (Outlook Exchange for Microsoft, Wildcat! 
Exchange for us), they begin to offer the same Online Experience in an 
offline fashion.

But when it comes to email via store and forward, like POP3 and SMTP, 
that offline emulation of online requirements become much harder.  For 
DKIM, the pressure is higher to make sure the backend (MSA, MDA) to do 
the security filtering and if you do this in a single source manner, 
then you satisfy both online and offline needs.  This is a good 
example where Authentication-Results header is only fully trusted at 
the backend only.

However, if we are trying to push these controls to the Offline MUA, 
without having control of the MUA products designs, its becomes much 
harder.

I can see that problem very clearly with my AT&T "Your Online Billing 
is Available" email notifications.  They have promoting increasingly 
users to go online and for those popping in, they send these monthly 
unsigned emails with html links. I don't trust them so I ignore them.

But every month I do view the message source to see if there are any 
DKIM signatures.  I believe there was a period there was some DKIM 
signature, but it stopped.  Looking at these headers with the body 
content, you can clearly see, whether it was by design or the symptom 
of young engineers only dealing with html and online access, the 
intent is online access to secure the communication with the users 
which would not added to their spam box.

I think a piece of the problems in the WG is that are trying to design 
for RFC-based MUAs in mixed ways, when in practice, the direction is 
going back to online access (i.e. smaller mobile devices now taken for 
granted in this new generation).

You also have new centralization and cloud designs with Apple, Google 
and Windows the principles in these proprietary networks and there is 
a movement for an trusted identity egosystem (see NSTIC - National 
Strategic for Trust in CyberSpace).  This might even help DKIM with 
certification, but I still see it needing to reconsidered author 
identities again :)

So my view has always been that you need to secure online first, then 
try to emulate the offline RFC rendering as much as possible without 
compromising on the security.

-- 
HLS