Subject: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 17 Jun 2011 22:05:09 +0200

Dear all,

after some off-list conversation with Dave he suggested I might want to 
send this to the list. I apologize in advance if this message does not 
apply to you. I also apologize if you get this message twice, when you 
are subscribed to both ietf-dkim and the opendkim list.

The Dutch government maintains a list of standards, which can/should be 
used by the Dutch government and semi-government, to improve 
interoperability. This list is called the 'comply or explain' list: if a 
government body has very good reasons to not comply, they can get away 
with it, but if they have no good reasons, they have to use the 
standards that are on this list in the various area's they apply, to 
improve interoperability. To give some examples: ODF is on the list, as 
well as IPv6. The complete list can be found at 
http://www.open-standaarden.nl/fileadmin/os/documenten/OS_lijst_open_standaarden_voor_pas_toe_of_leg_uit.pdf, 
unfortunately there is no English version of it, AFAIK. Background 
information can be found at 
*http://standards*.gov/*standards*_gov/sos_rfi_docs/47_*Netherlands*.pdf. By 
some people this list of standards is also seen as a list of standards, 
that need some extra support to achieve a critical mass, to solve the 
problem of chicken-and-egg that's often a problem in standards acceptance.

Last year in November I submitted DKIM as a candidate for this list. 
Now, before it will be accepted for the list 'comply or explain', there 
are a number of steps to be taken. One of these steps will be an expert 
group meeting in July; in this expert group people from government, 
semi-government, industry etc. are present, to give their view about 
whether DKIM should or should not be on this list.

Now the committee, that is preparing this expert group meeting, is happy 
with gov/semigov and industry participation, but they also want some 
technology experts in the expert group meeting (of course, why else 
would it be called an expert meeting :-)). Unfortunately the experts 
will have to have the Dutch nationality, or at least speak Dutch, I'm 
not sure why; it seems to be a matter of rules.

Now my question is: if you're a Dutch member of this list, or you know 
someone who is/speaks Dutch and has expertise in the area of DKIM please 
let me know. The website with information about the expert meeting can 
be found at:

http://www.open-standaarden.nl/actueel/item/titel/oproep-aanmelden-voor-expertgroepen/

(ignore the deadline of June 8th). If you're interested, send mail to 
[email-masked] and refer to this mail. Please note: it is 
possible that a selection will be made, to achieve a balance in the 
expert meeting group between the various parties, or to limit the number 
of members of the expert group.

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

---

From: Franck Martin <[email-masked]>
Date: Sat, 18 Jun 2011 02:23:25 +0000

Have you contacted people at ripe? They usually have a good handle on anything Internet. I would try to speak to Daniel Karrenberg or Mirjam Kuehne.

From: "Rolf E. Sonneveld" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 17 Jun 2011 22:05:09 +0200
To: IETF DKIM WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

Dear all,

after some off-list conversation with Dave he suggested I might want to send this to the list. I apologize in advance if this message does not apply to you. I also apologize if you get this message twice, when you are subscribed to both ietf-dkim and the opendkim list.

The Dutch government maintains a list of standards, which can/should be used by the Dutch government and semi-government, to improve interoperability. This list is called the 'comply or explain' list: if a government body has very good reasons to not comply, they can get away with it, but if they have no good reasons, they have to use the standards that are on this list in the various area's they apply, to improve interoperability. To give some examples: ODF is on the list, as well as IPv6. The complete list can be found at http://www.open-standaarden.nl/fileadmin/os/documenten/OS_lijst_open_standaarden_voor_pas_toe_of_leg_uit.pdf, unfortunately there is no English version of it, AFAIK. Background information can be found at http://standards.gov/standards_gov/sos_rfi_docs/47_Netherlands.pdf. By some people this list of standards is also seen as a list of standards, that need some extra support to achieve a critical mass, to solve the problem of chicken-and-egg that's often a problem in standards acceptance.

Last year in November I submitted DKIM as a candidate for this list. Now, before it will be accepted for the list 'comply or explain', there are a number of steps to be taken. One of these steps will be an expert group meeting in July; in this expert group people from government, semi-government, industry etc. are present, to give their view about whether DKIM should or should not be on this list.

Now the committee, that is preparing this expert group meeting, is happy with gov/semigov and industry participation, but they also want some technology experts in the expert group meeting (of course, why else would it be called an expert meeting :-)). Unfortunately the experts will have to have the Dutch nationality, or at least speak Dutch, I'm not sure why; it seems to be a matter of rules.

Now my question is: if you're a Dutch member of this list, or you know someone who is/speaks Dutch and has expertise in the area of DKIM please let me know. The website with information about the expert meeting can be found at:

(ignore the deadline of June 8th). If you're interested, send mail to [email-masked]<mailto:[email-masked]> and refer to this mail. Please note: it is possible that a selection will be made, to achieve a balance in the expert meeting group between the various parties, or to limit the number of members of the expert group.

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Jun 2011 11:47:53 -0700

> are subscribed to both ietf-dkim and the opendkim list.
[]
> /rolf

Hi Rolf,

The general goal of DKIM was to establish a domain relationship as a 
trust basis for acceptance.  DKIM was also to allow incremental 
deployment without requiring undefined additional filtering performed by 
mail transfer or mail user agents.  When essential format checks are 
skipped, this deficiency allows acceptance based upon DKIM's domain to 
be potentially deceptive where its results may play an evil role that 
cannot be repaired through the use of reputation.

Free email providers likely use DKIM to take advantage of their "too big 
to block" volumes.  For these domains, their reputation is understood to 
offer little assurance of their overall integrity.  By allowing a 
pre-pended From header field to not affect the validity of a DKIM 
signature according to the specification means the UNDERSTOOD source of 
a message can NEVER be trusted.

Those that phish by taking advantage of this flaw are unlikely to affect 
the acceptance of any exploited high volume domain.  DKIM could have 
avoided the offering of false assurances by not ignoring illegal header 
fields per RFC5322 and defining such messages as resulting in invalid 
signatures.  At this time, it would be prudent to NOT recommend use of 
DKIM due to this and a lack of required Fake A-label detection.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 23 Jun 2011 12:16:26 +0000

> DKIM due to this and a lack of required Fake A-label detection.

This seems like a completely bogus argument to me. You're saying that some domains can't be trusted, therefore none can be trusted. That's a logical fallacy. 

Sure, gmail.com can't be trusted because they'll sign even spoofed emails. So, my server won't be configured to give a pass to emails signed by gmail.com However, that doesn't mean that I can't be more lenient with respect to emails signed by, for example, subdomains of  .gov.uk, which might well be better managed.

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Jun 2011 12:00:25 -0700

On 6/23/11 5:16 AM, Ian Eiloart wrote:
>> The general goal of DKIM was to establish a domain relationship as
>> a trust basis for acceptance.  DKIM was also to allow incremental
>> deployment without requiring undefined additional filtering
>> performed by mail transfer or mail user agents.  When essential
>> format checks are skipped, this deficiency allows acceptance based
>> upon DKIM's domain to be potentially deceptive where its results
>> may play an evil role that cannot be repaired through the use of
>> reputation.
>>
>> Free email providers likely use DKIM to take advantage of their
>> "too big to block" volumes.  For these domains, their reputation is
>> understood to offer little assurance of their overall integrity. By
>> allowing a pre-pended From header field to not affect the validity
>> of a DKIM signature according to the specification means the
>> UNDERSTOOD source of a message can NEVER be trusted.
>>
>> Those that phish by taking advantage of this flaw are unlikely to
>> affect the acceptance of any exploited high volume domain.  DKIM
>> could have avoided the offering of false assurances by not ignoring
>> illegal header fields per RFC5322 and defining such messages as
>> resulting in invalid signatures.  At this time, it would be prudent
>> to NOT recommend use of DKIM due to this and a lack of required
>> Fake A-label detection.
>
> This seems like a completely bogus argument to me. You're saying that
> some domains can't be trusted, therefore none can be trusted. That's
> a logical fallacy.

Not at all.  Acceptance policies and results for DKIM MUST align with
what is being displayed in the message.  Otherwise malefactors may be
able to exploit open and large volume domain's signatures and their lack
of duplicates in the signed header list (which most don't do).  The
pre-pended header fields could then be that of any high value domain.
These messages might have been accepted on the false premise of being
from a high volume domain when based upon valid DKIM signature indications.

Dave and Murray have made some strange arguments about whether DKIM
should ensure valid signatures not contain multiple From header fields
and then say such checks are some other undefined protocol's burden.

There is a significant difference between SHOULD and MUST.  Using
the term SHOULD in regard to generic message format compliance (which
only recommends compliance per RFC2119) does not clarify whether there
are cases where it would be okay for valid signatures to contain
multiple From header fields.  Would insistence that a different protocol
make these checks be a good reason to ignore their occurrences?

  From: Accounts Manager <big-bank.com> (displayed and not signed)
  DKIM-Signature: h=from,subject,date, d=free-email-provider.com ...
  Subject: Please review your account status immediately
  From: [email-masked] (not displayed but signed)
  ...

  <html content>
  <corporate logos>
  You can review your account at <bogus-link>.
  </html content>

Even if big-bank.com were to use multiple headers in their 'h=' list,
the evaluation of the signature would be based upon that of
free-email-provider.com which only lists single headers.

Dave also insists rfc822 prohibited the use of multiple From headers, 
but it only states multiple headers are discouraged.  Explicit 
limitations expressed using ABNF syntax does not occur until rfc2822, 
some 19 years later.  Not to fault Dave who was only the author.  It was 
a different era where rfc822 was a substantial accomplishment having a 
primary goal of facilitating gateway translations that often mandated 
only minimums.

As it is now, one can not expect SMTP will reject messages that violate 
rfc5322, although that is what appears to DKIM expect.  Unless someone 
can give examples were it would be okay to have multiple From header 
fields within a valid DKIM signed message, it would be much safer to 
have the DKIM specification stipulate the singular requirement as a MUST.

> Sure, gmail.com can't be trusted because they'll sign even spoofed
> emails. So, my server won't be configured to give a pass to emails
> signed by gmail.com However, that doesn't mean that I can't be more
> lenient with respect to emails signed by, for example, subdomains of
>  .gov.uk, which might well be better managed.

What if free-email-provider.com ensures their signed From headers 
contain their domain or one confirmed using a ping-back?  Do you 
understand the nature of the concern?

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jun 2011 17:52:52 -0400

> Acceptance policies and results for DKIM MUST align with
> what is being displayed in the message.

I'm pretty sure that we have uniformly agreed not to attempt to do MUA 
design, so, no, it doesn't.  We have no idea what is displayed in the 
message.  We have no idea if the message will ever be displayed at all.

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: Douglas Otis <[email-masked]>
Date: Thu, 23 Jun 2011 19:46:47 -0700

> message.  We have no idea if the message will ever be displayed at all.
Ian,

John is right.  Most headers are displayed selecting top-down and DKIM 
always selects bottom-up.  Headers likely displayed and selected to be 
signed need to be check by some protocol layer that ensures they are not 
illegally pre-pended.  Unfortunately, both SMTP and DKIM will not make 
these basic checks.  There seems to be a prevailing assumption undefined 
spam filters will instead intercede.  Who should victims blame when 
these checks are not made?  How can a secure system be specified?

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jun 2011 23:34:05 -0400

> John is right.  Most headers are displayed selecting top-down

If you'll review the message you were quoting, I said "We have no idea 
what is displayed in the message." I have done some experiements, and MUAs 
are utterly inconsistent.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Jun 2011 21:20:54 -0700

On 6/23/11 8:34 PM, John R. Levine wrote:
>>> I'm pretty sure that we have uniformly agreed not to attempt to do 
>>> MUA design, so, no, it doesn't.  We have no idea what is displayed 
>>> in the message.  We have no idea if the message will ever be 
>>> displayed at all.
>> Ian,
>>
> what is displayed in the message." I have done some experiements, and 
> MUAs are utterly inconsistent.
Assuming this is some other protocol layers problem; to ensure 
consistency between any possible display and DKIM validation, this can 
only be done by excluding illegal duplicates from verifying as valid 
DKIM signatures.  Is there any other way?  In such a case, the selection 
order of the MUA or email sorter would not matter.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jun 2011 00:55:38 -0400

> Assuming this is some other protocol layers problem; to ensure consistency 
> between any possible display and DKIM validation, ...

  ... is, for about the hundredth time, not DKIM's job.

Please chant "we have no idea how MUAs will display mail" over and over 
until you believe it. This includes valid 5322 mail.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 24 Jun 2011 09:20:59 +0000

> from a high volume domain when based upon valid DKIM signature indications.

Right, but DKIM is checked at the MTA. If I think that messages DKIM signed by, say, my local council, are trustworthy, then I apply a spam score accordingly. The fact that someone else might spoof a From: header in a different mail stream says nothing about whether I can trust the stream from my local council.

So, it may be that the practical outcome is to improve the deliverability of mail for a trusted signer, which is a different problem. But that's still useful. With ADSP, of course, there's also a chance of spotting spoofed messages.

And, if multiple "From:" headers become a popular spoofing mechanism, I guess sites will stop accepting them.

I accept that DKIM doesn't solve every problem, but that doesn't mean that it has no value.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 24 Jun 2011 11:44:58 +0000

> until you believe it. This includes valid 5322 mail.

So, heck, what's the point in validating anything? After all, the MUA may simply display this message as a link to a canadian pharm site!

I think we can be pretty sure that - if there's only one "From:" header - then the MUA won't display an unsigned From: header in preference to a signed one.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 24 Jun 2011 11:42:14 +0000

On 24 Jun 2011, at 03:46, Douglas Otis wrote:

> these checks are not made?

They should blame (a) the spammer, and (b) their local MTA operator. 

Even though we don't do MUA design, somebody has to. It's helpful if there's a set of people in the world that have considered these issues, and can give advice on them.

>  How can a secure system be specified?

With this particular issue, it seems that an MTA could simply insist that a message comply with RFC5322's requirement that there be exactly one "From:" header. Now, we could say in DKIM that a signature is invalid if there's more than one From: header present in the message. Or we could informally advise MTA or MUA designers that ignoring RFC5322's requirements here is inadvisable, since DKIM has that assumption. 

For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers.

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jun 2011 08:55:34 -0400

> For me, as an MTA operator, I'm happy that I have justification for 
> rejecting messages with the wrong number of From: headers.

I have pointed out at least six times, that in the extremely unlikely 
event that bad guys were to send mail with double From headers you can 
just dump it, since no real mail has more than one.  You don't need DKIM 
for that.  Spam filters have detected spam by looking for technical 
message flaws for over a decade, and this is just another one.

I don't know how to say that any more clearly.  Perhaps you can explain it 
to Doug.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Jun 2011 10:24:15 -0400

> I think we can be pretty sure that - if there's only one "From:" header - then
> the MUA won't display an unsigned From: header in preference to a signed one.

No, but, for example, we have no idea whether an MUA will show any of
these things, or something else entirely:

> From: Barry Leiba <[email-masked]>

> From: [email-masked]

> From: [email-masked] on behalf of Barry Leiba

> From: [email-masked] on behalf of Barry Leiba

> From: Barry Leiba

> From: Leiba

> From: Barry

There are more variants of this in heaven and earth, folks, than are
dreamt of in your philosophy.  But come; Here, as before, never, so
help you mercy, is it DKIM's responsibility to sort it out.

Barry

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2011 16:35:39 +0100

On Fri, 24 Jun 2011 05:55:38 +0100, John R. Levine <[email-masked]> wrote:

>> consistency

Precisely so. Which is why, this being a secuity protocol, we have to  
presume that MUAs will do whatever will make life most difficult from a  
DKIM POV, and design a protocol which works in spite of that. This we have  
signally failed to do.

In the present situation, we need to presume that MUAs will display the  
first instance only of any duplicated header (which is a pretty safe  
presumption given that the most communly used MUA does just that).

The AD has been made aware of this problem, and has concluded that the  
present 3.8 will suffice (though he has caused a missing reference to the  
proper oart of section 8 to be added). Whilst I disagree with his  
conclusion, I have decided not to take the matter any further (and Doug  
and Rolf are aware of my decision).

-- 
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: Dave CROCKER <[email-masked]>
Date: Fri, 24 Jun 2011 09:58:19 -0700

On 6/24/2011 5:55 AM, John R. Levine wrote:
> I have pointed out at least six times,
...

Let's simplify this discussion:

    Spammers do a variety of techniques to trick filters and users.

    We should have the DKIM signing specification normatively require checking 
for every known technique, since we cannot be sure that any other part of the 
system will perform the necessary checks.

d/
-- 

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

---

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

> system will perform the necessary checks.

+100

But sadly the consensus of this WG was otherwise :-(

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Jun 2011 10:51:03 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Monday, June 27, 2011 2:43 AM
> To: DKIM
> Subject: Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list
> 

Mmm, I think Dave was being sarcastic.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 27 Jun 2011 11:01:00 -0700

On 6/27/2011 10:51 AM, Murray S. Kucherawy wrote:
>>> We should have the DKIM signing specification normatively require
>>> checking for every known technique, since we cannot be sure that any
>>> other part of the system will perform the necessary checks.
>>
>> +100
>>

Dave thinks so, too.

Dave even thought that was pretty obvious, but Dave should have known better.

The term for the class of exercise I described is "boiling the ocean"... 
Alternatively is requires already knowing what is not known.

d/

-- 

   Dave Crocker

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 27 Jun 2011 14:38:36 -0700 (PDT)

On Fri, 24 Jun 2011, Dave Crocker wrote:
> checking for every known technique, since we cannot be sure that any other
> part of the system will perform the necessary checks.

Leaving aside the fact that Dave is kidding above, for those who think
that is a good idea on it's face, I'd like to reiterate my suggestion for
this problem:

* Put it in its own RFC *

I think there's room for a "Minimum Quality of Forgery Supression" BCP.
Such an RFC would outline a number of faults a message can have, and
declare that any of those faults mean the message MUST NOT be delivered
to the nominal recipient.

ISPs would then promise to follow this RFC, and in return
phishing-sensitive institutions may reward users who give contact
addresses at a compliant ISP, such as an exemption from a "phishing
insurance" fee.

To be actually useful, such a standard would need to reach beyond DKIM
and ADSP.  For example, some sort of means to prevent full-name abuse
(Paypal <[email-masked]>) or mispellings (<[email-masked]>)
would be vital.  Those are hard problems, the DKIM people should not have
to be weighed down working on them.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jun 2011 09:13:25 +0200

> to the nominal recipient.

+1, revising RFC 2505, whose date is in last century, should be due.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Jun 2011 06:29:37 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, June 28, 2011 12:13 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] spam filtering 101
> 

Actually I suspect this might be a different document, since the claimed attack isn't necessarily specific to spam.  Such a new document might make a lot of references to RFC2505.

On the other hand, if RFC2505bis was geared (and re-titled) toward more general abuse prevention, it would make more sense.

In any case, it seems unlikely this group will re-charter to do that, so someone could take it up as an independent submission or bring it to the APPSAWG or something like that.