Subject: DKIM Signatures now being applied to IETF Email

From: Glen <[email-masked]>
Date: Mon, 25 Jul 2011 10:17:48 -0700

All -

I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing list email from mailman.

Many thanks to Murray Kucherawy, lead author of OpenDKIM, for doing the work
to set up OpenDKIM on the IETF servers and getting it to work.  He made the
process painless, and we express our thanks to him for his service to the IETF.

As always, any questions or issues, please feel free to contact me, or submit
to ietf-action.

Thank you,

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Jul 2011 14:01:04 -0400

> to all outgoing list email from mailman.

I'll be presumptuous and speak on behalf of the DKIM operations community, 
rather than just myself:

   Cool!  Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Jul 2011 00:07:47 -0400

Cool beans.  Message as verified here.  The good thing is that it 
finally resolved the corruption of distributed original signed mail on 
the ietf list server with its extra line at the top!

Glen wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Jul 2011 00:19:40 -0400

But the original destroyed signature from the author is not stripped.

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=fail policy=all author.d=isdg.net asl.d=ietf.org (unauthorized 
signer);
  dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 
header.i=isdg.net;
  adsp=pass policy=all author.d=isdg.net signer.d=isdg.net 
(originating signer);

It would be nice for the list server to remove original signatures the 
list will destroy in its resigning process.  That may be an OpenDKIM 
option.

What I need to do now also is authorized IETF.ORG as a valid 3rd party 
signer for the ISDG.NET domain.  This is done by adding ADSP/ATPS 
record using this wizard:
http://www.winserver.com/public/wcadsp/wcadsp.wct

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jul 2011 10:46:06 +0200

On Mon, Jul 25, 2011 at 10:17:48AM -0700,
 Glen <[email-masked]> wrote 

> to all outgoing list email from mailman.

What about a RFC 5617 published signing practice?

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jul 2011 14:02:42 +0200

> But the original destroyed signature from the author is not stripped.

Nor verified, apparently.

>  adsp=fail policy=all author.d=isdg.net asl.d=ietf.org (unauthorized signer);
>  dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 header.i=isdg.net;
>  adsp=pass policy=all author.d=isdg.net signer.d=isdg.net (originating signer);

My verifier is somewhat more concise than yours.  For your message it
just reports

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass header.i=@ietf.org;
  dkim-adsp=fail header.from=[email-masked]

> list will destroy in its resigning process.

That implies checking which signatures actually got destroyed.  Was
the author signature destroyed, on this message?  Possibly not, as on
my previous message I got

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass header.i=@tana.it

(The IETF's signature would probably have passed too, but since the
author signature was good, this concise verifier didn't bother to
report on any other one --a little bit too much concise, perhaps.)

---

From: Sean Turner <[email-masked]>
Date: Wed, 27 Jul 2011 08:09:03 -0400

On 7/25/11 2:01 PM, Dave CROCKER wrote:
> I'll be presumptuous and speak on behalf of the DKIM operations
> community, rather than just myself:
>
> Cool! Thanks.

+1 to that!

Personally, I like it when we eat our own dog food ;)

spt

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2011 13:23:08 -0000

>What about a RFC 5617 published signing practice?

That RFC is only useful for a narrow range of heavily phished domains
like Paypal's.  Fabulous though the IETF is, it's not one of them.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Jul 2011 09:37:24 -0400

> What about a RFC 5617 published signing practice?

ADSP only works when the domain in the From: field is the same as the signer's 
domain name.  It really is tailored to use by highly phished sites acting as 
fully-integrated bulk senders.  It cannot work with more diverse environments.

The IETF email environment qualifies as extremely diverse.  Our mailing list 
operation breaks ADSP.

d/

-- 

   Dave Crocker

---

From: "t.petch" <[email-masked]>
Date: Thu, 28 Jul 2011 18:34:12 +0200

---- Original Message -----
From: "Sean Turner" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 27, 2011 2:09 PM

> > community, rather than just myself:

-100

The minor point is that e-mails have just got yet bigger.  They are now 100-150%
bigger than when first I started following the IETF and it is not that people
have more to say, but that the junk at the front has expanded out of all
recognition.  This costs, transmission time, processing storage etc.  The
transmission time is significant (I imagine) because of POP3 which seems to take
2n+ messages, n round trips, before starting to download anything out of n
e-mails.

But more importantly we have abolished the end-to-end principle.  If I am going
to benefit from improved security on e-mail, I want to from the originator to
me, not some half-way house giving a spurious impression of accuracy.

Tom Petch

---

From: "John R. Levine" <[email-masked]>
Date: 29 Jul 2011 01:12:08 -0400

> me, not some half-way house giving a spurious impression of accuracy.

I can't help but be baffled at the lack of a PGP or S/MIME signature on 
your message.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jul 2011 11:09:29 +0200

On 28/Jul/11 18:34, t.petch wrote:
> bigger than when first I started following the IETF

According to Nielsen's Law, network connection speeds double every 21
months.  DKIM is apparently using a quite reasonable fraction of that.

> me, not some half-way house giving a spurious impression of accuracy.

Most users don't want perfect accuracy into the mail system.  Not only
because of the burden of maintaining keys, but also for concerns about
freedom of speech, right to anonymity, possibility to play jokes, and
the like.  MSA endorsement allows all that, and still delivers some
responsibility by leveraging the trust between authors and their
mailbox providers.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Jul 2011 06:18:22 -0400

> me, not some half-way house giving a spurious impression of accuracy.

The end-to-end principle is often cited as an argument for any mechanism that is 
not the end-nodes.  I'm waiting for the day it is applied to a demand that every 
user's computer, tablet and smartphone be directly connected to every other one, 
so that we no longer suffer IP relaying by routers, since their presence 
violates the end-to-end principle.

With respect to DKIM, the problem with your concern is that you appear to 
misunderstand the function DKIM is performing.  Since that's well-documented, I 
suggest you review how it works and what it means.  In case that's too much 
effort, I suggest you take a look at:

    The Truth About DKIM
    <http://bbiw.net/presentations/DKIM%20Truth.pdf>

specifically slide 4.  The left hand side includes a short list of common 
mis-assumptions about DKIM's meaning, along with the one correct one.  See 
whether you know which is the right one.

d/

-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Jul 2011 06:36:22 -0400

On Jul 29, 2011, at 6:18 AM, Dave CROCKER wrote:

> The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes.  I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle.
> 
> With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing.  Since that's well-documented, I suggest you review how it works and what it means.  In case that's too much effort, I suggest you take a look at:
> 
>   The Truth About DKIM
> specifically slide 4.  The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one.  See whether you know which is the right one.

DKIM is not my favorite protocol.  But it's not like there haven't been several efforts to define e2e authentication for email, including PEM, S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at the moment.    Implementations of email clients that support e2e authentication are not hard to find, and some people do use them.   But they've never been widely used.  I don't blame the DKIM proponents for wanting to try a different deployment model, for a different use case.

Keith

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Jul 2011 08:09:28 -0400

oh boy...

On 7/29/2011 6:36 AM, Keith Moore wrote:
>> The Truth About DKIM <http://bbiw.net/presentations/DKIM%20Truth.pdf>
>>
> DKIM is not my favorite protocol.  But it's not like there haven't been
> several efforts to define e2e authentication for email, including PEM,
> S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at

Since DKIM's semantic is fundamentally different from PEM, S/MIME and OpenPGP, I 
don't know why you cited them.

For the typically uses of 'authentication' with respect to email, DKIM does not 
do authentication.  Please re-read the preceding sentence 10 times.

I really do suggest folks who have comments about DKIM first put some effort 
understanding what it does and does not do.

We've made it easy.  There are multiple documents discussion what it is and how 
to use it.

>  I don't blame the DKIM proponents for
> wanting to try a different deployment model, for a different use case.

DKIM is a different semantic, not just a different implementation.

d/

-- 

   Dave Crocker

---

From: "t.petch" <[email-masked]>
Date: Fri, 29 Jul 2011 14:22:15 +0200

---- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 29, 2011 12:18 PM
> whether you know which is the right one.

Yes, I know enough about DKIM to identify the right one.

I think that it is an error for the IETF to add DKIM signatures.  They do indeed
tell me
which intermediary has sent me the mail, but does nothing for the 'spam' that
the
intermediary accepted in the first place (albeit there being little of that on
the IETF
managed lists).  And has already been pointed out, the mailing list damages any
DKIM signature that is already there.  I find it interesting that John Levine
lists
'DKIM doesn't work with mailing lists'
as one of this three myths.  I think that that depends on the interpretation of
the word 'work'.  I would say that DKIM in this context, of a mailing list,
gives
a spurious impression of increased security that we would be better off without.
It functions, but does not work, in that it tells me nothing about the true
origin of the communication.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Jul 2011 06:43:53 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Friday, July 29, 2011 5:22 AM
> To: [email-masked]; ietf
> Subject: Re: DKIM Signatures now being applied to IETF Email
> 

...but that's not what it's supposed to tell you.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jul 2011 11:02:21 -0400

> managed lists).
...
> origin of the communication.

What it does is allow you to assure yourself that the message was,
indeed, from an IETF mailing list (well, from an IETF email server),
and that it wasn't that someone tried to spoof that.  That, in turn,
allows you to confidently increase your trust that the message is not
spam in proportion to your confidence in the IETF's spam-filtering
capabilities.

Some of us, at least, find that useful.  Some of us might even
completely white-list IETF-signed messages.  You can make your own
choice on that.

Barry, DKIM WG chair

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Jul 2011 12:55:48 -0400

> completely white-list IETF-signed messages.  You can make your own

An intermediary that signs messages and has a reputation for carrying spam in 
its stream will have an appropriate reputation.  One that signs messages and has 
a clean message stream will also have an appropriate reputation.

The differences between the two will produce very different disposition at the 
delivery site.

All of which is cleaner and safer than is possible today, except with 
constrained uses of previous-hop IP(v4) addresses.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Jul 2011 01:42:03 -0400

> origin of the communication.

Yes and No and that the main problem with DKIM, which I see is the 
lack of 3rd party signal controls or put another way - anyone, middle 
ware and especially list servers can blindly DKIM resign mail without 
restrictions.  That lack of control has cause originating authoring 
domains, copyright holders of mail, all benefits of supporting DKIM.

The current approach is that original domains no longer have any 
rights whatsoever to declare they are the only signers allowed to sign 
mail and any deviation from that expectation should be indication of 
protocol failure - "Reject it!"

Unfortunately, in order to allow a list server or any 3rd party 
middleware to exist with DKIM (re)signing features, it needs to ignore 
any original DKIM domain signing practice or expectations.

No domain that wishes exclusive signing operations should be sending 
their signed mail to a public service forum.   We know this, but we 
don't have the controls to disallow faults or bad guys attempting to 
create a facsimile of your domain signed mail in public areas or 
directly to others.

Finally, as DKIM was revamped from secured Author-Domain signing 
protocol to a "anyone can signed" 3rd party Trust vendor protocol, the 
problem we face is we don't have consistency with 3rd party trust 
tables.   For DKIM to work, every validators needs a copy of the same 
trust tables.  DKIM is a protocol that requires Batteries in order to 
work and everyone must use the same batteries.

---

From: "t.petch" <[email-masked]>
Date: Sat, 30 Jul 2011 12:26:13 +0200

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "ietf" <[email-masked]>
Sent: Friday, July 29, 2011 5:02 PM

...

<tp>
Yes, I do understand that - having read the first round of DKIM RFC
when they came out all those years ago - and do see it as a useful
tool for improving the security of e-mail and I should have made
that clearer in my first e-mail.

Sadly, I do not see it being used in the mailing lists where an
organisation is sending me directly data I would like to be able to rely on
- which I think fits the applicability well - and instead, I see it
being used on a mailing list such as those in the IETF where I
believe that the costs outweigh the benefits - and I have no choice
about that:-(.

Tom Petch

Barry, DKIM WG chair

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 30 Jul 2011 07:45:19 -0400

> believe that the costs outweigh the benefits - and I have no choice

Costs?

1. The only place that DKIM information appears in a message is in a special 
header-field.

2. If your system does not process DKIM and you don't display the full header, 
you don't even see that it is there; unlike OpenPGP and S/MIME, there is no 
evidence of DKIM in the body.

3. The increase in size in message size is felt by the industry to be a minor 
"cost", especially given all the other functions that already increase message size.

4. If the extra bytes are such a terrible burden for you, strip the field off.

It does seem odd to complain about a mechanism that (finally) provides a 
certifiably valid identifier on messages, in an environment where 90% of the 
traffic across the Internet exploits the fact that there hasn't been one...

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Jul 2011 08:16:15 -0400

Dave CROCKER wrote:

> certifiably valid identifier on messages, in an environment where 90% of 
> the traffic across the Internet exploits the fact that there hasn't been 
> one...

How it is certified?  I haven't seen any DKIM message that comes with 
a certified identifier. Is there consistency in the certification 
across all DKIM verifiers? What do you when it isn't certified which 
is 99% of the DKIM signed mail coming in?   And how does one leverage 
or mitigate this 90% asserted exploitation with DKIM?  Should we begin 
to reject mail that do not have valid signatures?

Without a domain policy based security wrapper, DKIM remains an 
unsecured protocol and currently it is just wasted processing 
bandwidth with a huge cost in implementation and management, or just 
plain old getting it right, and even then, most people in our market 
don't understand what utility it offers them.  At present, they 
believe the "new badge" will help them look better, but there is no 
real evidence that it does anything for them.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Jul 2011 22:00:08 -0700

> Sent: Saturday, July 30, 2011 3:26 AM
> To: Barry Leiba
> Cc: ietf

There has been some post-DKIM talk recently about the idea of "transient trust", wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that "covered" it.  Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise.

This hasn't been widely deployed yet, but some big email providers are currently playing with the idea.

---

From: Hector Santos <[email-masked]>
Date: Sun, 31 Jul 2011 06:12:04 -0400

You continue to not comprehend (or rather ignore) what continues to 
plaque DKIM - the lack of fault detection. Its why it continues to 
have a hard time and have people who actually believe in this 
promising protocol "bitch" about it.  If these "big email" providers 
(or anyone for that matter) begin to make assertions about what is 
good about their mail then they better be ready for the violations of 
such assertions to be rejected.  You can't have it just one way and 
mandate this is the only way to process this overhead - looking for 
good mail only and ignoring all the violations and illogically 
treating it like it was never signed or compromised or attempted to be 
compromised.

The overall difficulty is that originality is lost - the original 
author or dkim signer has lost or lacks any protocol guidance to tell 
resigners that the mail they are about the process might be bad - 
according to the original author domain.

If the resigner is going to intentionally and neglectfully ignore all 
original claims about the original domain signing practice, then how 
do you expect the anonymous "copy-cat" abuse to be controlled?