Subject: [ietf-dkim] review of draft-ietf-dkim-overview-01

From: EKR <[email-masked]>
Date: Tue, 11 Jul 2006 10:47:35 -0700

Overall comment: ISTM that a lot of the document is explicit
advocacy for DKIM and in some places it's perhaps more enthusiastic
than necessary.

S 1.2.1:
   pass today without some form of strong authentication mechanism.
   DKIM provides such a strong authentication mechanism.

I think calling DKIM a "strong authentication mechanism" in view
of the dependence on DNS is probably too uh, strong.

In the difference list, I would add that it's domain only signing.

In the difference list:

   o  there is no dependency on public and private key pairs being
      issued by well-known, trusted certificate authorities,

This isn't a property of any previous e-mail signature systems
either. They depend on issued certificates, not issued key
pairs. 

   o  there is no dependency on the deployment of any new Internet
      protocols or services for public key distribution or revocation,

I think this is a bit misleading. DKIM depends partly on DNSSEC
for security, and that is not yet widely deployed.

S 1.2.2
   the basis for evaluating whether to trust the message for delivery.

I'm not sure "trust" is a useful word here.

   The owner of the domain name being used for a DKIM signature is
   declaring that they are accountable for the message.  This means that
   their reputation is at stake.

I'm not sure I understand what reputation means in this context.

   o  does not require the use of trusted third parties (e.g.,
      certificate authorities) which might impose significant costs or
      introduce delays to deployment

See discussion on the mailing list about DNS servers being TTPs.

S 3.3.2, 3.3.3.

Note: these are unfinished..

S 5.2:
   While modern messaging infrastructure is considerably friendlier to
   the use of digital signatures than in the past even a residual
   failure rate of 1% results in unacceptably high support costs when
   signatures are used ubiquitously.

While this may well be true, it's asserted without evidence.

S 5.4:
   The Kohnfelder architecture was originally designed to allow use of
   public key cryptography before the ubiquitous availability of
   networking.  A particular benefit of the Kohnfelder architecture is
   that Alice can send an encrypted message to Bob when the only
   transport available is sending floppy disks through the postal
   system.  Another benefit of the Kohnfelder architecture is that a
   signed message supported by a digital certificate is self supporting
   and may be verified years after the fact provided only that the CA
   signing key does not become compromised.

   The principle weakness in PKIs based on the Kohnfelder architecture
   is the difficulty of locating the correct digital key in the absence
   of a directory infrastructure.  This led Brian LaMacchia, then at MIT
   to develop the MIT PGP key server, in effect returning to the
   original public key directory model proposed by Whitt Diffe and Marty
                                                   ^^^^^^^^^^^
                                                   Whit Diffie

   Hellman.

This claim strikes me as rather strange.... Remember that X.509 *was*
intended to work with a directory, indeed The Directory (X.500). So,
while it's certainly true that it's hard to get keys, it's not that
the guys who designed it were somehow too stupid to know about
directory systems.

S 5.5

   As previously mentioned PGP and S/MIME were designed in the heyday of
   the security end-to-end principle.  It has since been realized that
   the end points with respect to trust are not the same as the end
   points with respect to the communication protocol.

   When Alice sends a personal message to Bob it is Alice the person,
   not the machine Alice happens to be using that is the true trust end
   point.  When Alice sends a piece of business correspondence to Bob it
   is her employer.

I don't think this is necessarily true. Rather, the issue is that the
application here (e-mail responsibility attestation) is different
from the ordinary e-mail signature issue.

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jul 2006 21:06:52 +0200

Hi Eric,

I would generally agree with you about the enthusiasm of the document. 
This is probably a good place for it, so long as it's accurate.  I would
> for security, and that is not yet widely deployed.

I believe the point Dave is trying to make is that you don't need to
deploy a huge infrastructure to deploy DKIM.  DKIM does NOT require
DNSSEC.  Deploying DNSSEC improves the security of DKIM in the face of
DNS attacks.
> I'm not sure "trust" is a useful word here.

The intent is to state that if you know who you're dealing with you can
decide how best to dispose of the message.
> I'm not sure I understand what reputation means in this context.

I believe it would be pedantic to define a commonly used English word.
> While this may well be true, it's asserted without evidence.

I agree.  If you're going to cite statistics provide the cite.
>    original public key directory model proposed by Whitt Diffe and Marty

I read Dave's claim is to the contrary.  They presumed a directory
infrastructure that in fact has proven difficult to widely deploy to the
level of the individual.
> from the ordinary e-mail signature issue.

I agree that this assertion is poorly worded, to say the least.  For
one, I believe it has always been the case the the binding between
protocol end points and "trust end points" has been a matter of debate. 
I would suggest sticking with the idea that we are attempting to make a
weaker assertion - that the message originated from a particular domain
and that its contents have not been tampered with since departing that
domain, and nothing more at this point.

Eliot

---

From: EKR <[email-masked]>
Date: Tue, 11 Jul 2006 12:20:09 -0700

Eliot Lear <[email-masked]> writes:

> deploy a huge infrastructure to deploy DKIM.

Well, in that case you could argue the same thing about S/MIME,
which can work in opportunistic (only partly secure modes).

>  DKIM does NOT require
> DNSSEC. 

And S/MIME doesn't require PKI.

> Deploying DNSSEC improves the security of DKIM in the face of
> DNS attacks.

In the face of attacks which we know happen....

> decide how best to dispose of the message.

That's fine, but trust is a word with a complicated history.

> I believe it would be pedantic to define a commonly used English word.

I disagree.
1. It's a technical term in the security community, and since there's
   no reputation service being proposed..
2. As I've pointed out before, manual forensics about who actually
   sent a message aren't really *that* difficult. Transmitting a message
   at all puts your reputation on the line--to the extent that sending
   spam damages your reputation.

> infrastructure that in fact has proven difficult to widely deploy to the

Hmm... I don't read it that way. The beginning of 5.4 says:

   Unlike all four previous IETF email security initiatives, DKIM
   employs a key centric, directory based PKI as opposed to a
   certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman
   (web of trust).

Which seems to suggest that X.509 isn't directory-based. But as I
noted, the original design certainly was....

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jul 2006 22:18:50 +0200

> which can work in opportunistic (only partly secure modes).

Right.  See below about weaker claims and the lack of a fully deployed
PKI.  It is designed primarily to scale to the level of a domain.
> And S/MIME doesn't require PKI.

S/MIME has its own set of problems, which I won't rehash.

> In the face of attacks which we know happen....

In those places where that's important perhaps we'll see DNSSEC
deployment, then.

> That's fine, but trust is a word with a complicated history.

I agree.

>    no reputation service being proposed..

The language was plainly used.  You are, however, raising two separate
issues: use of the term and whether reputation services are in scope. 
They are clearly not.  However, that doesn't mean that DKIM cannot be
used by such services, and it certainly doesn't mean that we must never
refer to them.  This having been said, I still believe the plain
language reading connotes an obvious meaning.

>    spam damages your reputation.

Forensics != verification.

> noted, the original design certainly was....

While I could see how you could take this one sentence out of context
and view it as poorly worded, let's agree that the author does not
believe X.509 was implemented outside the notion of a directory.  Let me
suggest, therefore, that you propose wording to clarify.

Eliot

---

From: EKR <[email-masked]>
Date: Tue, 11 Jul 2006 13:33:36 -0700

> S/MIME has its own set of problems, which I won't rehash.

Of course. My point is merely that DKIM has some set of advantages
vis-a-vis S/MIME and PGP, but that this draft overstates
them.

> In those places where that's important perhaps we'll see DNSSEC

Right, so I don't think it's reasonable to claim that there's
no dependency.

> language reading connotes an obvious meaning.

Hmm... I don't. Not sure what else to say.

> Forensics != verification.

And verification != reputation. What's your point?

> and view it as poorly worded,

What a strange argument, since I also posted several paragraphs which
I also believe imply the same thing.  You may not agree with my reading,
but I don't see why you're arguing that I'm taking it out of context.

> let's agree that the author does not

I would, but I don't really understand what the paragraph
is intended to mean.

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Jul 2006 16:12:02 -0400

> noted, the original design certainly was....

There are likely those who will argue DNS not offer a directory  
either, but rather a label tree.  A major difference between these  
services is how registration is handled.  The nature of DNS  
registration allows name acquisition without accountability.  The  
concept of a trust service should encompass both publishing _and_  
registration.  Care should be taken not to diminish this sizable  
distinction.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 08:26:42 -0400

I did a quick read of -overview yesterday and on the whole liked it. 
It's a bit rough, lots of spelling/grammar errors, obviously written 
by different people, needs sections filled in, etc., but it seemed 
like it covered the critical areas.  I'll try to read it in more 
detail soon.

However, there was one sub-thread between EKR and Eliot that left me 
a bit confused:

--On July 11, 2006 10:18:50 PM +0200 Eliot Lear <[email-masked]> 
wrote:

>>>>    The owner of the domain name being used for a DKIM signature
>>>>    is declaring that they are accountable for the message.  This
>>>>    means that their reputation is at stake.
>>>>
>> 1. It's a technical term in the security community, and since
>> there's no reputation service being proposed..
>>
>
> The language was plainly used.  You are, however, raising two
> separate issues: use of the term and whether reputation services
> are in scope.  They are clearly not.  However, that doesn't mean
> that DKIM cannot be used by such services, and it certainly doesn't
> mean that we must never refer to them.  This having been said, I
> still believe the plain language reading connotes an obvious
> meaning.

I thought that the Overview document was supposed to be a 
non-normative introduction (ok, "overview") of DKIM: motivations, 
context, how the pieces fit together, how it fits into the bigger 
picture.  If I'm right, then

(1) using "plain English" is just fine, and hence "reputation" 
doesn't need a formal (normative) definition; and

(2) reputation /is/ in scope of this document, since it speaks to the 
bigger picture.

Have I misunderstood the intent of -overview?  If it is to be a 
normative document then I will suddenly have a /lot/ of comments....

eric

---

From: <[email-masked]>
Date: Wed, 12 Jul 2006 09:10:07 -0400

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

Number 1 below is partially true. I can send mail that appears to be
from someone else that cannot be tracked back to the actual originating
IP but appears to be from elsewhere, this is what I hope DKIM can solve.
Thanks,
Bill

There are two potential meanings of "reputation" here.

1. The "plain English" one of "you look bad". As I noted previously,
   your reputation is already on the line when you forward e-mail,
   since people can manually verify that you sent it. This is 
   how black-hole lists work. DKIM doesn't add this feature.
2. The technical sense of "reputation services", but as I mentioned
   earlier, this is out of scope for DKIM, and of course it's
   not plain English...

-Ekr

---

From: EKR <[email-masked]>
Date: Wed, 12 Jul 2006 05:38:16 -0700

Eric Allman <[email-masked]> writes:

> I did a quick read of -overview yesterday and on the whole liked
> it. It's a bit rough, lots of spelling/grammar errors, obviously
> written by different people, needs sections filled in, etc., but it
> seemed like it covered the critical areas.  I'll try to read it in
> more detail soon.
>
> However, there was one sub-thread between EKR and Eliot that left me a
> bit confused:
>
> --On July 11, 2006 10:18:50 PM +0200 Eliot Lear <[email-masked]> wrote:
>

I have a conflict with DKIM so phoning this in...

> (1) using "plain English" is just fine, and hence "reputation" doesn't
> need a formal (normative) definition; and

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jul 2006 14:08:12 -0400

> I thought that the Overview document was supposed to be a non-normative
> introduction (ok, "overview") of DKIM: motivations, context, how the
> pieces fit together, how it fits into the bigger picture.  If I'm right,
> then
> 

I had the same reaction, when initially reading the EKR/Lear exchange.

The problem is that we are, nonetheless, within a technical realm.  While the
document probably has a wider audience than -base or -ssp, the -overiew document
can't claim to exist in isolation.  So we need to be careful that we not create
confusion.

Frankly, I'd prefer to use a non-technical term, when intending a non-technical
meaning.  That's why I usually say "vetting" or "vouching".

> (2) reputation /is/ in scope of this document, since it speaks to the

correct.

-- 

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

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 15:26:02 -0400

--On July 12, 2006 2:08:12 PM -0400 Dave Crocker <[email-masked]> 
wrote:
> The problem is that we are, nonetheless, within a technical realm.
> While the document probably has a wider audience than -base or
> -ssp, the -overiew document can't claim to exist in isolation.  So
> we need to be careful that we not create confusion.
>
> Frankly, I'd prefer to use a non-technical term, when intending a
> non-technical meaning.  That's why I usually say "vetting" or
> "vouching".

In the spirit of using plain English, I think "reputation" is better, 
because that's the term that the press is using and hence what people 
know.  However I agree with EKR that we need to be clear about what 
we really mean here, since after all the press often misuses the word 
in ways that we don't intend.

So, I'll 50% reverse my previous statement and say that "reputation" 
does need a definition, but it doesn't have to have a formal, 
normative definition.  In fact, trying to come up with a normative 
definition /would/ be out of scope.

eric

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jul 2006 17:01:37 -0400

Eric Allman wrote:
> know.  However I agree with EKR that we need to be clear about what we
> really mean here, since after all the press often misuses the word in
> ways that we don't intend.
> 
> does need a definition, but it doesn't have to have a formal, normative
> definition.  In fact, trying to come up with a normative definition
> /would/ be out of scope.

I know I should not pursue this further, but I just can't help myself:

There is very serious confusion in the public AND in the email anti-abuse
community, about the terms "reputation" and "accreditation". Most folks within
the anti-abuse community have clear and defininitions that make a useful
distinction between the two.  The problem is that the odds that any two such
folk are using the same definitions is low.

In the more general public, the term is too diffuse to have much meaning.

Although it we might well not be able to change to poor use among the media, I
believe we ought to try to be careful within our own community.

d/

-- 

  Dave Crocker

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 07:06:10 -0400

So Dave, is this a vote for a formal definition?

eric

--On July 12, 2006 5:01:37 PM -0400 Dave Crocker <[email-masked]> 
wrote:
> There is very serious confusion in the public AND in the email
> anti-abuse community, about the terms "reputation" and
> "accreditation". Most folks within the anti-abuse community have
> clear and defininitions that make a useful distinction between the
> two.  The problem is that the odds that any two such folk are using
> the same definitions is low.
>
> Although it we might well not be able to change to poor use among
> the media, I believe we ought to try to be careful within our own
> community.
>
> d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 07:14:35 -0400

Not by DKIM.

Moving the community to a common vocabulary involving vetting is not DKIM's job.

It's a battle that should be fought by the folks in the vetting business.

DKIM should use a generic term that isn't one of the terms of art.

d/

Eric Allman wrote:
> --On July 12, 2006 5:01:37 PM -0400 Dave Crocker <[email-masked]> wrote:

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 07:55:23 -0400

Eric Allman wrote:
> I don't think I agree with this.  First, since by your own argument
> these terms aren't properly defined, using yet another poorly defined
> term to mean the same thing doesn't exactly seem to be improving the
> situation.  

Well, we are already making a point of playing this ambiguity game, in terms of
the term "responsible":

>From the abstract:

> The ultimate goal of this framework is to permit
>    a signing domain to assert responsibility for a message

Yet we are extremely careful to leave the precise meaning of "responsible"
unstated.  We have fought the tempation to provide that definition and I
continue to claim that that is a Very Good Thing for us to continue to do. It is
an issue that is actually outside the scope of DKIM's solution.

We provide a mechanism that enables the folks for whom it IS within scope, but
we don't (need to) do it ourselves.

We need to be quite precise and consistent about the term authentication, since
that's DKIM'sjob.  The higher level stuff isn't.

Also, since the overview is supposed to be an informative
> document that paints the scene for reading the rest of the documents,
> using a term that is likely to make people scratch their heads works
> against the goal.

A fair point of view.  However I would much rather have the Overview document
cite some of the terms of art that get used, offering them merely as exemplars
of activities that will use DKIM, but not actually define those words, except in
terms of a more generic word.  This might lead to sentences that are less crisp
(elegant) but keeps us the heck out of the briar patch of the
reputation/accreditation.

So, for example:

> 1.2.2.  What is the purpose of DKIM?
> 
>    DKIM lets an organization take responsibility for a message.  The
>    organization taking responsibility is a handler of the message,
>    either as its originator or as an intermediary.  Their reputation is

might become:

1.2.2.  What is the purpose of DKIM?

   DKIM lets an organization take responsibility for a message.  The
   organization taking responsibility might be a handler of the message,
   as its originator or as an intermediary, or it might be a third-party vetting
   service.  Their recipient assessment of the signer provides
   the basis for evaluating whether to trust the message for delivery.

NOTE:

   I've had to deal with a second issue, in the above text:

   Signers will not necessarily be the folks moving the message.

   This came up when Goodmail first started getting public discussion and I
suggest a scheme that would allow such third-party services to sign a message
using DKIM.  Obviously, their involvement requires the cooperation of a handling
agent, but the handling agent isn't doing the signing.

d/
-- 

  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jul 2006 14:35:22 +0200

Dave,

When we can no longer use the common meaning of words to convey their
meaning we have REALLY gone 'round the bend.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 09:06:02 -0400

> meaning we have REALLY gone 'round the bend.

What part of "based on empirical observation around the communities that are
using the term, there is no common meaning" was I not clear about?

d/

-- 

  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jul 2006 15:35:51 +0200

> using the term, there is no common meaning" was I not clear about?

Common sense dictates that a dictionary like Websters provides a common
definition.  It further dictates that technical authors as well as
others should AVOID redefining commonly used terms, as that confuses the
reader, since we are not computer programs who can easily honor local
bindings.  Further, this is not some some legalistic document, but a
non-normative overview.

And so if Eric has a problem with the use of the term reputation,
perhaps he could sub in this common definiton and tell us if he *still*
has a problem, what that problem is, and what wording would correct the
problem.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 10:07:27 -0400

Eliot Lear wrote:
> definition.  

Various responses, such as noting how uncommon, common sense is, come to mind.

But rather than go down that path, I will simply note that citing a dictionary
definition does not change usage problems that occur at a societal level.

d/
-- 

  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jul 2006 13:37:29 +0200

> So Dave, is this a vote for a formal definition?

For crying out loud.  Here is the definition from Marion Webster's.

Main Entry: *rep·u·ta·tion*
Pronunciation: "re-py&-'tA-sh&n
Function: /noun/
Etymology: Middle English /reputacion,/ from Anglo-French, from Latin
/reputation-, reputatio/ consideration, from /reputare/
*1 a* *:* overall quality or character as seen or judged by people in
general *b* *:* recognition by other people of some characteristic or
ability <has the /reputation/ of being clever>
*2* *:* a place in public esteem or regard *:* good name <trying to
protect his /reputation/>
- *rep·u·ta·tion·al*  /-shn&l, -sh&-n^& l/ /adjective/ 	

This is the common meaning of the term that matches the document's use.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 08:00:38 -0400

> For crying out loud.  Here is the definition from Marion Webster's.

Eliot,

I fear that I have failed to make clear that a dictionary definition is entirely
irrelevant.

The fact that it is irrelevant is an example of the larger problem that I am
trying to have us NOT deal with:  The term is used in different ways by
different people in the community.

We do not solve the problem of differential use by merely citing the dictionary.
 Were it that simple, the differential use issue would have been solved a few
years ago.  (It's not as if the problem wasn't seen clearly by many folk, long
ago and it isn't as if they have ignored the problem.)

The problem of different uses for the same word requires changing the behavior
an entire community of technical, marketing, news, and other folk.

We have enough on our plates.  We don't need to add this task to it.

d/
-- 

  Dave Crocker

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 07:25:54 -0400

situation.  Also, since the overview is supposed to be an informative 

I propose instead that we use some term that resonates with readers, 
but (informally) define it in the document to minimize 
misunderstanding.

eric