Subject: [ietf-dkim] Comments on -overview document?

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Jul 2006 13:53:16 -0400

Folks,

It would be helpful to see some comments on the mailing list about the Overview
document that we've drafted, before the Wednesday session.

Th document is very rough form, so that pointing out redundancies and awkward
wordings, and the like, is probably not where anyone should spend their time.
Still, the document is really quite extensive.

So what I hope we DO get feedback on is about its general organization and
scope, orientation of the different sections, and other such strategic aspects
of the document.

Let me lobby about one particular issue:  We currently do not have anything that
really explains what DKIM is, at a service or non-technical level.  That is, we
have the algorithmic details, in the -base document, but nothing that really
describes the overall, end-to-end service.  The current Overview draft includes
some text that attempts to remedy this.  (It has lots more, but I wanted to
mention this particular portion of it.)

d/
-- 

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

---

From: <[email-masked]>
Date: Sun, 9 Jul 2006 20:06:39 -0400

Dave,
if you are speaking to the 
http://mipassoc.org/dkim/info/DKIM-Intro-Allman.html it looks good except the piece at the bottom of page 6 

:::Not an anti-spam technology by itself

should be amplified

:::Not an anti-spam technology by itself but a methodolgy to clearly identify a responsible party as part of the email sending and delivery process.

otherwise it looks good.
thanx,
bill

-----Original Message-----
From: [email-masked] on behalf of Dave Crocker
Sent: Sun 7/9/2006 1:53 PM
To: ietf-dkim
Subject: [ietf-dkim] Comments on -overview document?
 
Folks,

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Jul 2006 21:37:14 -0400

[email-masked] wrote:
> http://mipassoc.org/dkim/info/DKIM-Intro-Allman.html 

oops.  sorry.  no.

I meant:

> 	Title		: DomainKeys Identified Mail Overview
> 	Author(s)	: T. Hansen, et al.
> 	Filename	: draft-ietf-dkim-overview-00.txt
> 	Pages		: 30
> 	Date		: 2006-6-22
> 	
>    DomainKeys Identified Mail DKIM [I-D.ietf-dkim-base] 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 proving and protecting message sender identity and the integrity
>    of the messages they convey while retaining the functionality of
>    Internet email as it is known today.  Proof and protection of email
>    identity, including repudiation and non-repudiation, may assist in
>    the global control of "spam" and "phishing".
> 
>    This document provides an overview of DomainKeys Identified Mail and
>    how it can fit into overall messaging systems, how it relates to
>    other IETF message signature technologies, implementation and
>    migration considerations, and outlines potential DKIM applications
>    and future extensions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-00.txt
> 

announced on 22 June.

d/

-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Sun, 9 Jul 2006 19:41:36 -0700

>> http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-00.txt

Try

http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-01.txt

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 09:00:59 -0400

Dave,
This document fine except for the following section
"Usually, email is i/o-intensive, with unused
   computational capacity.  So, it is likely that no new hardware will
   be required."

This should be deleted. For example if others in my organization who
have not followed the mailing list were to see that paragraph they would
conclude that the WG did not have a clear understanding of today's large
mail environment and would tend to resist implementation efforts. The
paragraph above that gives a 10 to 15% processing utilization should
speak to what cpu, what architecture those numbers came from if we are
going to include any numbers at all.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, July 09, 2006 9:37 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Comments on -overview document?

oops.  sorry.  no.

announced on 22 June.

d/

-- 

  Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Jul 2006 10:59:54 -0700

In addition, this number is what both Murray/Eric and I are seeing as 
sendmail
*milters*, which is much more likely to be an *upper* bound rather than
a lower bound or typical result. I've been trying to tease out what the 
actual
computational cost is lately, but it's not really easy as it depends a 
lot on
how much trafffic needs to be signed, how much is signed, how long the
average DNS latency is, etc, etc, etc.

       Mike

[email-masked] wrote:

>>   cryptography and key server technology to permit verification of
>>    
>>
>the
>  
>
>>   source and contents of messages by either Mail Transfer Agents
>>    
>>
>(MTAs)
>  
>
>>   thus proving and protecting message sender identity and the
>>    
>>
>integrity
>  
>
>>   This document provides an overview of DomainKeys Identified Mail
>>    
>>
>and
>  
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jul 2006 15:40:48 -0400

> going to include any numbers at all.

Bill, it seems reasonable to add some language that constrains the assertion.

That said, numbers in the range of 5-15% have been produced by a variety of
independent sources.  I believe this includes 2 very large service and one very
experienced vendor.

The issue about probably needing no new hardware certainly depends upon how
loaded one's server already is.

d/

-- 

  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Jul 2006 22:07:02 +0200

Bill,

I think what Dave could say is that in I/O intensive environments DKIM
will have a negligible impact because minimal disk I/O is required.  If
your environment is not I/O bound then of course DKIM will have a
marginal impact.  If you're using your CPUs efficiently already, good on
you!

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jul 2006 16:11:26 -0400

> will have a negligible impact because minimal disk I/O is required.  If

The counter-point, to claims that email is i/o bound, is that modern
requirements for filtering alter the equation quite a bit.

That's why I was intrigued to hear the comments about being i/o bound come from
folk doing empirical -- real-world -- testing of DKIM.

That said, these days it is nearly always true that one can set up a server hub
to use most of the cpu, no matter how much i/o they have.

d/

-- 

  Dave Crocker

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 16:14:56 -0400

(forgot to hit reply to all)
Eliot,
I think we should treat the issue by stating that in the mixed
environments currently being tested a 10 to 15% cpu usage has been
noted. This will allow the SA types to adequately engineer a DKIM
solution based on their layout. When you think of all the edge
processing, filters, heuristics, etc, that is almost all cpu. The only
IO problems I have is trying to find an ever increasing mound of
storage.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked]

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Monday, July 10, 2006 4:11 PM
To: Eliot Lear
Cc: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] Comments on -overview document?

That's why I was intrigued to hear the comments about being i/o bound
come from
folk doing empirical -- real-world -- testing of DKIM.

That said, these days it is nearly always true that one can set up a
server hub
to use most of the cpu, no matter how much i/o they have.

d/

-- 

  Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Jul 2006 13:26:07 -0700

>marginal impact.  If you're using your CPUs efficiently already, good on
The point that Bill brings up, however, is a good one and I suspect that 
he's
entirely right if one considers the _inbound_ which is very likely to be 
very
CPU bound with anti-spam/virus/malware/etc. Still in that case, it's not 
clear
that the DKIM overhead is likely to be very significant as the main cost for
smallish messages may not even be bound to the RSA and/or SHA overhead
(seeing how RSA verifies are so much cheaper than signing).

In any case, I think he's right that in order to give advise we'd do 
well to
actually state the test cases for which somebody could do their own
experimenting.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 10 Jul 2006 13:48:46 -0700

On Jul 10, 2006, at 1:26 PM, Michael Thomas wrote:

> The point that Bill brings up, however, is a good one and I suspect  
> that he's
> entirely right if one considers the _inbound_ which is very likely  
> to be very
> CPU bound with anti-spam/virus/malware/etc. Still in that case,  
> it's not clear

Arguably, DKIM allows easy whitelisting of high-volume senders, allowing
the recipient to skip content-based spam filtering for that mail. That's
likely to be a significant fraction of inbound mail, so may reduce  
the CPU
overhead overall.

> In any case, I think he's right that in order to give advise we'd  
> do well to

Definitely.

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 11 Jul 2006 14:10:02 -0400

> http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-01.txt

I hope you don't a problem with the criticism, but I have an problem with
the following subjective opinion statements in section 5.2:

   It is now generally accepted that the correct semantics for an email
   signature verifier to adopt are to treat messages with signatures
   that fail as if they are unsigned.

I don't get it. Why are you continuing trying to "mold" people thinking to
ignore Failure Analysis?  You have absolutely no control over this. I can
almost guarantee you that as DKIM moves into the mainstream and people being
to realize the unprotected nature of this protocol facsimile,  you have
absolutely no control or mandate over how people will analyze their junk. If
they see a pattern related to BAD DKIM signatures, rest assured people are
not going to ignore it.  Anyway, it doesn't make sense.  You can't remove
the markings of a failure by simply saying "ignore it."

   It is highly unlikely that an attacker is going to add a digital
   signature to a message unless doing so causes the message to be
   treated more favorably than an unsigned one.

Again, not true. You have no clue what attackers will do. And just as the
CODERED and SORBIG viruses/worms have shown the world-wide industry,
attackers most definitely use the concept of attacking population
and numbers of legacy/flawed systems. It is a proven methodology used over
and over again.  They will use fake DKIM signatures or even promote them as
bad if a population of "ignore the bad" systems prevail across many default
systems.  The reason?  You stated it yourself:

   Any messages that carry signatures that fail verification are
   thus much more likely to be a genuine message that has been
   damaged in transit than an attempted forgery.

And for this reason, the attacker will hope this is exactly what you
expect to prevail -  the creation of a mindset that errors are not malicious
but more than likely the natural exhaust of the new DKIM system. It is
highly probable they will exploit this flaw.

Finally, I think this this pushing of "responsibility" mantra
alittle too much to the extent, if it becames standard, it can create new
legality issues.

It think it is inconsistent to promote responsibility when there are no
assurance that controls are predictable or expected at the verifiers.  With
the lack of policy verification controls, I think organizations will think
twice about wanting to take responsibility when the odds are high that
verification is going to be a weak aspect on DKIM.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com