Subject: Re: bozoproofing the net, was The Value of Reputation

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2006 11:35:28 -0500

--On Sunday, 01 January, 2006 04:35 +0000 John Levine
<[email-masked]> wrote:

> I hope the message here is not that we should restrict
> ourselves to developing technology that is idiot-proof, since
> a sufficiently determined idiot, of which there are many, will
> do idiotic things with any technology that we never in a
> million years would have anticipated.

No.  I don't believe in idiot-proof technologies.  I do believe
that it is not desirable to create standards that would give a
gift of either technology or justification to those who would
use them to fragment the network.  I believe it is especially
important to avoid those gifts when the people or groups
involved are quite sophisticated about using technologies to
maximize their short-term  economic gain at the cost of global
communications and interoperability.

People and companies with those sorts of motivations will
undoubtedly do their thing regardless of what we do.  But we
don't need to help them or provide them with justification via
"we are just following the standard".

And I still believe that we should do this work.  I just believe
that the work should include some real discussion, and analysis
of workarounds, about how uses of the technology that are
interoperability-hostile, or global-communications-hostile, can
be prevented or clearly identified as inappropriate.  Think of
it as an explicit "interoperability considerations" section to
supplement the usual "security considerations" one.

>...
> One favor that the SPF crowd did for us was to give the
> aforementioned idiots a chance to find out what a bad idea it
> is to reject mail arbitrarily from people who don't jump
> through their hoops, so nobody rejects for SPF failure any
> more.  People who use C/R against people not on their
> whitelists have found the same thing -- they all check the
> folder of unconfirmed mail because they know there's lots of
> real mail from people who won't hoop jump.
> 
> If the idiots were to latch on to DKIM and start rejecting
> valid mail, like they have to the past umpteen magic bullets,
> why do you expect the results to be any different?

I note that we have never standardized a magic bullet in the
anti-spam area.  I believe that to have been a good trend.  To
the credit of a significant fraction of the DKIM advocates, they
haven't claimed it is a magic bullet, which is also a good trend.

If there is agreement on what you say above (I think there
probably is) and it can be documented, then some explicit
warnings about that experience and its applicability would
satisfy most or all of my concerns.  I wouldn't expect to see
merely "doing X is bad and you MUST NOT do that", but rather "X
should be avoided because there is documented experience that
its consequences are Y and Z".

best,
   john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2006 12:14:59 -0500

> Think of it as an explicit "interoperability considerations" section to

That seems reasonable, so long as someone steps forward to write it.

> I note that we have never standardized a magic bullet in the anti-spam
> area.  I believe that to have been a good trend.

Perhaps this would be a good time to remind people that they can build a
spam-proof walled garden today with S/MIME.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Jan 2006 10:19:32 -0800

John K., et al,

Feliz año nuevo; Selamat tahun baru.

>   I do believe

I suspect we will not find anyone in the IETF who thinks otherwise.  Certainly 
my own reaction to your statement, here, was "Yes!! Absolutely Correct!"

Then I tried to consider the implications of the statement, in the current 
context, and I realized that I have no idea what pragmatic import it has.

I have no idea how to apply this caveat to the DKIM work.

DKIM is DKIM. As a technology it has a specific intent and its core is 
well-defined -- and actually pretty simple -- with well-understood properties. 
The core is similar to a number of technologies that have been in use for at 
least 15 years.

So I need to ask that you express your concern as a specific recommendation for 
changes to the DKIM charter text, lest this thread be merely 
comforting-but-irrelevant (or, worse, -distracting) to the DKIM effort.

On the matter of insisting that specifications document various alerts and 
caveats, again we are faced with a dilemma.  After all, who could possibly 
object to the task of educating potential users of a technology about its 
weaknesses?

Yet an open-ended requirement for such warnings a) to my knowledge has no 
empirically demonstrated efficacy, and b) often has the real effect of 
providing a large barrier with long delays.

That is, we insist on including such discussions out of a sense of professional 
responsibility, rather than out of any knowledge that such discussions in IETF 
specifications have real utility for the success of those specifications.

The real impact of this barrier is to delay gaining exactly the field experience 
that will demonstrate *real* efficacy and *real* problems, rather than imagined 
ones.

(It seems to me that this underscores the problematic change in the process of 
trying to do work in the IETF, namely that we should raise any and all barriers 
based on fear, rather than find ways to facilitate efforts so they gain 
field-experience.)

> "we are just following the standard".

There are legitimate technical weaknesses in any technology.  It is essential to 
be aware of them and decide whether they need to be addressed with changes to 
the specification of that technology.

However, that is quite different from attempting to engage in analysis of the 
psychosocial vagaries that can lead to abuse of an otherwise-legitimate 
technology.

The IETF has neither the mandate nor the community skill at conducting such 
analyses.  Our efforts to perform such analyses is usually marked by an 
amateurish FUD ogre and diffusion of constructive effort.

> And I still believe that we should do this work.

That's good to hear.

   I just believe
> interoperability-hostile, or global-communications-hostile, can

Again:  This sounds eminently reasonable, until I start to realize that I do not 
know what you mean.

> satisfy most or all of my concerns.  

Again:  Please translate this into a specific recommendation for charter 
language, with appropriate modifications to the schedule.  Please include an 
explanation for the intended benefit of the work item and the basis for 
believing that the benefit will be realized.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Douglas Otis <[email-masked]>
Date: Sun, 1 Jan 2006 15:49:31 -0800

On Jan 1, 2006, at 8:35 AM, John C Klensin wrote:

>> I hope the message here is not that we should restrict ourselves  
>> to developing technology that is idiot-proof, since a sufficiently  
>> determined idiot, of which there are many, will do idiotic things  
>> with any technology that we never in a million years would have  
>> anticipated.
>
> that it is not desirable to create standards that would give a gift  
> of either technology or justification to those who would use them  
> to fragment the network.  I believe it is especially important to  
> avoid those gifts when the people or groups involved are quite  
> sophisticated about using technologies to maximize their short- 
> term  economic gain at the cost of global communications and  
> interoperability.

The risks related to interoperability will more likely result from  
assuming authorization authenticates the source.  This authorization  
strategy may benefit larger domains, but will be corrosive to goals  
of interoperability and integrity.  To avoid the misapplication of  
this mechanism, there are suitable alternatives to authorization for  
the DKIM effort.  DKIM offers a significant value without  
authorization to establish expectations.  Not endorsing authorization  
schemes also discourages possible burden-shifting of the short- 
comings of DKIM.  Hopefully, not allowing this tactic will lead to a  
better, safer, and far more fair solutions.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2006 21:21:54 -0500

--On Sunday, 01 January, 2006 15:49 -0800 Douglas Otis
<[email-masked]> wrote:

>...
> The risks related to interoperability will more likely result
> from  assuming authorization authenticates the source.  This
> authorization  strategy may benefit larger domains, but will
> be corrosive to goals  of interoperability and integrity.  To
> avoid the misapplication of  this mechanism, there are
> suitable alternatives to authorization for  the DKIM effort.
> DKIM offers a significant value without  authorization to
> establish expectations.  Not endorsing authorization  schemes
> also discourages possible burden-shifting of the short-
> comings of DKIM.  Hopefully, not allowing this tactic will
> lead to a  better, safer, and far more fair solutions.

Indeed.  And, along the lines of my response to John, and to
Dave's request to be specific, that sort of analysis and
description is _precisely_ what I believe should be required to
be written into text, get WG rough consensus on its
appropriateness and accuracy, and then make its way into the
WG's deliverables.

If agreement on such comments can be reached, I believe that
such a requirement is reasonable and not particularly
burdensome.  If such agreement cannot be reached, then I think
DKIM has much more serious problems about applicability and the
definition of the problems being solved than whether or not this
is required.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Jan 2006 19:20:43 -0800

>   If such agreement cannot be reached, then I think

John,

Unfortunately what you appear to be saying is that you are certain of serious 
problems, and  are happy to assert them as a barrier to progress -- after all, 
you want to insist that a requirement for dealing with your fears be included as 
a chartered deliverable -- but you do not feel compelled to provide a solid 
basis for these fears.

Before imposing requirements on an IETF effort, one should make a pragmatic case 
for it.  At base, the case you have so far made is that the reasonable mechanism 
of DKIM might get mis-used, just as any other reasonable mechanism might be.

You keep implying that it is somehow a mysterious and big deal to have a 
voluntary, validated identity associated with message transit.

It isn't.

And the real fear that we all should have is that it is being characterized as a 
bigger deal than it is, including that its supposed "dangers" are vast and unknown.

Let's start with something simple and useful, John:

    Are there technical deficiencies in the current DKIM specifications?

If there aren't, then please cite previous IETF work that requires worrying 
about unknown, future abuses and imposes those fears as a barrier to chartering.

d/

-- 

Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2006 22:53:15 -0500

> be written into text, ...

The more I think about this, the less sense it makes.  DKIM is not the
first misusable security technology to come along, nor will it be the
last.  What makes it so uniquely dangerous that it needs special warning
labels?

Consider HTTP over SSL.  It has exactly the same balkanization problem
today that you're concerned about.  Browsers are shipped with a fairly
random list of signing certs that have more to do with history and PR
budgets than with an objective standard of merit, and pages from any https
server that hasn't bought a signature from someone in the browser's list
provoke a scary warning message.  Yet I see no language in RFC 2818 or in
sections 2.3 and 2.4 of RFC 2459 (user and administrator expectations)
warning about the problem of balkanization due to arbitrary signer lists.

Or consider S/MIME.  S/MIME applications have a cert list similar to the
one in a web browser, so they also have the problem of dividing the world
into haves who can afford a cert with a signature from someone in the list
and have-nots who can't.  I haven't read every word of every S/MIME RFC
(there sure are a lot of them), but if there's any warnings about
balkanization, they're very well hidden.

Or how about DNSSEC?  As the problems of phishing and malware get worse,
and ICANN and IANA start putting signatures into the root zone, people
will inevitably come up with the bright idea that names in signed zones
are "secure".  Even better, in the absence of signatures all the way to
the top, people will start making lists of the islands of security that
they like to limit which signed zones they accept.  I would think that
warnings about this would have belonged in RFC 4033.

I really need clarification of why DKIM RFCs need to tell people about the
dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.
Since we will certainly be seeing more anti-spam and anti-phishing
proposals, what would be really useful would be a metric to decide when a
future proposal is more dangerous like DKIM and requires warning language,
or is less dangerous like the other three and doesn't.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 02 Jan 2006 08:44:05 +0100

> balkanization, they're very well hidden.

I think you are making John's point.......

There's a pair of facts (or what passes for facts) here:

- the IETF community has rejected the idea of mandating a single root for 
"just about anything" (except for the DNS, the IANA and the address spaces)
- Multiple roots lead to balkanization (of lesser or greater severity)

If these statements are both true, they might explain the lack of success 
of S/MIME as a tool for general (rather than balkanized) communication.

As far as I remember, neither of these statements have come out as 
consensus statements in any IETF document - perhaps because "everyone" 
knows that raising the issue will cause an endless debate and no consensus 
document?

Might be time to challenge that assumption....

                       Harald

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jan 2006 00:16:41 -0800

> If these statements are both true, they might explain the lack of 
> success of S/MIME as a tool for general (rather than balkanized) 
> communication.

and they might not.

Since you and we have no empirical basis for asserting the association between 
poor adoption and any particular characteristic of the thing that is not being 
adopted, it is not at all helpful to cite a particular (mere) possibility in 
this discussion.  It has no basis, so it has no relevance.

In other words, Harald, no John L. did *not* make John K.'s point.  Not even close.

 > - the IETF community has rejected the idea of mandating a single root
 > for "just about anything" (except for the DNS, the IANA and the address
 > spaces)

I don't recall the citation that documents this community consensus.  Can you 
provide it?

Oh, I see by your later text that you can't.  So what is your basis for saying 
"the IETF community has rejected"?  For that matter, I suspect you are wrong. 
For example, the IETF did standardize private re-use of address space, which is 
its own bit of balkanization.

 > - Multiple roots lead to balkanization (of lesser or greater severity)

Fine and true.

And your point is what, exactly?

I haven't seen anyone promoting multiple roots in this discussion, so how is 
this line of discussion at all relevant to the chartering of DKIM?

> knows that raising the issue will cause an endless debate and no 
> consensus document?

and perhaps because they are not consensus statements.

That's the problem with using guesses as facts.

And to that end, thank *you* for making *my* point about the problems that 
accrue from taking a guess -- such as what people might do with a new technology 
-- and trying to inject into a decision about whether to standardize the technology.

When did fear and psychosocial guesses become the basis for blocking IETF 
standards efforts?

d/

-- 

Dave Crocker

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 02 Jan 2006 10:54:12 +0100

Dave, if you have any facts to contribute to the discussion, it would be 
nice if you included them. I've chosen to interpret your note as some 
questions and comments on the hypothesis I advanced in my previous message, 
and have tried to supply some additional information below.

--On mandag, januar 02, 2006 00:16:41 -0800 Dave Crocker 
<[email-masked]> wrote:

> Since you and we have no empirical basis for asserting the association
> between poor adoption and any particular characteristic of the thing that
> is not being adopted, it is not at all helpful to cite a particular
> (mere) possibility in this discussion.  It has no basis, so it has no
> relevance.

The empirical fact is that I get some S/MIME signed mail. I cannot verify 
their origin, because my mailer does not have a certificate chain installed 
that allows the machinery installed in my mailer to do so. I have heard 
from others that the same thing happens to them. (And yes, my mailer has 
S/MIME verification software installed.)

This is a phenomenon that I've seen rather consistently over the years, and 
it seems to me that "no single root" is a reasonable description of this 
phenomenon.

It irritates me, and it's one reason why I use PGP/MIME rather than S/MIME 
when signing outgoing mail (I choose to have inflicted on me a different 
set of problems; neither solution works "well" for me, IMHO).
So for me personally, the fact of multiple roots is contributing to my own 
non-adoption of S/MIME. It seems to me that this is consistent with what 
others have reported.

I did not choose to repeat those observable facts; I chose to clearly label 
my hypothesis based on them a hypothesis ("might").

> I don't recall the citation that documents this community consensus.  Can
> you provide it?
>
> Oh, I see by your later text that you can't.  So what is your basis for
> saying "the IETF community has rejected"?  For that matter, I suspect you
> are wrong. For example, the IETF did standardize private re-use of
> address space, which is its own bit of balkanization.

I can't parse what I'm supposed to be wrong about here....
the IETF community seems to have rough consensus on what the IAB said in 
RFC 2826 about the DNS single root. In addressing, see RFC 1958 section 4.

As for the rejection of single roots - that's a hypothesis, and I'm 
advancing it as a hypothesis that seems to have reasonable predictive value 
- what one would expect if the hypothesis was true seems to match fairly 
well what happens in reality (no security standards work apart from DNSSEC 
seriously considers the option of mandating a single security root, and 
even DNSSEC  seems to choose to leave the decision on how the "root" is run 
to people outside the IETF community).

> I haven't seen anyone promoting multiple roots in this discussion, so how
> is this line of discussion at all relevant to the chartering of DKIM?

Actually, the subject line doesn't say anything about DKIM, so this thread 
is presumably about "Bozoproofing the net, was The Value of Reputation". 
But the current argument is actually somewhat relevant to DKIM.

DKIM (as I interpret it, and for this version) chooses a trust path that 
says "keys belonging to a domain sign messages". This means that each 
domain is its own "root".
The pieces that tie the "roots" together aren't specified in current DKIM; 
there's a good argument that it shouldn't be. One of the candidates for 
those pieces is called "reputation systems"; another, possibly orthogonal, 
is DNSSEC.

FWIW, I'm in favour of approving the DKIM charter in its present form, or 
something reasonably close to it (I don't object to adopting the charter 
language from XMPP, but it's not a showstopper either way for me). Some day 
(probably after experimentation), I think the community should return to 
specifying pieces that can be used for "the rest of the solution". But I'm 
all in favour of specifying DKIM without doing that first.

> That's the problem with using guesses as facts.

As far as I know, I'm using guesses as guesses. Also known as "theories".

> And to that end, thank *you* for making *my* point about the problems
> that accrue from taking a guess -- such as what people might do with a
> new technology -- and trying to inject into a decision about whether to
> standardize the technology.
>

Have you stopped beating your wife?

As far as I know, reasonable fears and well-funded guesses are a 
*reasonable* basis for making decisions, given that facts about what will 
happen in the future aren't available. It's my guess - and I think it's a 
reasonable one - that approving the DKIM charter roughly as-is will cause 
work to be done that has a good effect on the state of email in the future. 
But I can't claim that it's a fact.

It's the quality of the guesses that makes a difference, and it's our 
business to try to make the best guesses we can, based on as much fact as 
we can figure out.

                         Harald

PS: BTW: I've now finished "Crimes against logic".
http://www.alvestrand.no/books/crimes-against-logic.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jan 2006 03:19:25 -0800

Harald,

> nice if you included them.

Yes, it is always nice to include facts.  That is why I noted their absence from 
your assertions.

 > I've chosen to interpret your note as some
> questions and comments on the hypothesis I advanced in my previous 
> message, and have tried to supply some additional information below.

A note that says that you have made basic errors, that render your 
unconstructive to the current topic, probably qualifies as more than
"questions and comments".

> The empirical fact is that I get some S/MIME signed mail.  I cannot
> verify their origin, because my mailer does not have a certificate chain 
> installed that allows the machinery installed in my mailer to do so. I 
> have heard from others that the same thing happens to them. 

Taking a very small sampling, from a very limited community, and projecting it
onto a population of roughly 1 billion users, is not valid analytic methodology,
Harald.

Don't do it.

> This is a phenomenon that I've seen rather consistently over the years, 
> and it seems to me that "no single root" is a reasonable description of 
> this phenomenon.

Your discussion of no single root made two claims.  One was about the failure of 
s/mime failure and the second was about IETF community consensus.  The
fact that multiple roots can (and do) cause problems does not provide
substantiation for either of your claims.

So, you are taking my challenge on your logic as somehow indicating that I think
use of multiple roots is not often a problem.

Don't do that.

> I did not choose to repeat those observable facts; I chose to clearly 
> label my hypothesis based on them a hypothesis ("might").

The logic you are using is that a technology characteristic that causes you (and
some others) problems might be a reason for the relative failure of that
technology.  However, any interesting technology has lots of problems; this is
true even for successful ones.  Hence, the mere presence of a problem does not
qualify it as a basis for the failure of the technology.

In other words, Harald, anything "might" be a cause.  Adding the "might" does
not free up the speaker from being responsible for what they choose to suggest. 
  You chose what to claim "might" be responsible, but you have no basis for
that, other than a limited sampling of problem experiences.

In other words, Harald, absent a serious basis for citing the possible cause,
mentioning it is injecting mere noise into the dialogue.  Were we having a 
light-hearted discussion about the failure of s/mime, perhaps such casual 
reference to possible causes "might" make sense.  In a discussion about the 
chartering of DKIM, it makes none.

> RFC 2826 about the DNS single root. In addressing, see RFC 1958 section 4.

1. It represents IAB consensus.  IETF consensus on the document has never been
assessed, yet you appear to be claiming otherwise.

2. An assertion concerning the DNS root has no automatic generalization to a
principle that multiple roots is bad, yet that is what you have just attempted.

> advancing it as a hypothesis that seems to have reasonable predictive 
> value - what one would expect if the hypothesis was true seems to match 
> fairly well what happens in reality (no security standards work apart 

Harald, let's cut to the chase.  How is any of this relevant to the chartering
of DKIM? So far, this has become a frustrating exercise in fears and sloppy
logic.  If you have any facts to contribute to the question of chartering DKIM,
it would be nice if you included them.

Given your statement, here, it appears that you are calling for DKIM chartering
to be preceded by some sort of research project that attempts to assess the
diffusion of innovation failures for message signing.  I suspect that would
entail rather more delay than is reasonable, nevermind the challenge in
producing useful research results.

> Actually, the subject line doesn't say anything about DKIM, so this 
> thread is presumably about "Bozoproofing the net, was The Value of 
> Reputation". But the current argument is actually somewhat relevant to 
> DKIM.

You think that John K's note that you were responding to did not have DKIM as 
its focus?  I encourage you to re-read it.

> domain is its own "root".

What an interesting bit of logic.  Good thing you raised it, since the
application of your logic means that the distributed administration of domain
name and IP Address mappings -- essentially the same thing as domain name/key 
mapping is the result of multiple roots.  We had better fix that fast, since it 
must be causing failure of adoption of the Internet.

> The pieces that tie the "roots" together aren't specified in current 

It isn't?  You don't think that the administrative structure of the DNS might
mitigate this supposed problem, just a tad?

  there's a good argument that it shouldn't be. One of the
> candidates for those pieces is called "reputation systems"; another, 
> possibly orthogonal, is DNSSEC.

Huh?

Reputation systems have something to do with a single administrative root?

How?

> FWIW, I'm in favour of approving the DKIM charter in its present form, 

Good to know, since that is very much NOT what John K's note promotes.  He calls 
for adding a deliverable.

> As far as I know, I'm using guesses as guesses. Also known as "theories".

Harald, theories are supposed to have substantial basis, not stray bits of data.

> *reasonable* basis for making decisions, given that facts about what 

When we see any applied to this discussion, I'll agree with you.  So far, we 
haven't even come close, and I spent some effort explaining why.

Come to think of it, I do not recall seeing you respond to any of the substance 
of my comments.

Please consider less dismissive frivolity and more care and relevance in your 
assertions.

d/
-- 

Dave Crocker

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 02 Jan 2006 13:04:57 +0100

Dave,

I seem to have managed to provoke you to anger.

You, by continuing to attack the validity of my arguments without even 
attempting to address their substance, and attempting to chastise me for my 
logic while failing to apply any standards of rigor to your own, have 
managed to provoke me.

I think that this discussion, if followed further, will provide neither 
entertainment nor information to the IETF community.

Until further notice, I will not respond further to any statement you make 
in the IETF.
It's unlikely that I'll even read them.

                        Harald

---

From: Tony Hansen <[email-masked]>
Date: Mon, 02 Jan 2006 10:58:21 -0500

This thread was begun by the last call on the chartering of DKIM.

The thread of messages has wandered, with some people remembering its
roots (and others not), with some people taking into consideration the
history of the thread (and others not), and with some people trying to
keep the thread focused on its original topic (and others not). This has
led to different assumptions about what lies behind responses to
subsequent messages on the thread, and rancor because of those
assumptions and the messages arising from those assumptions. This is
disheartening.

Can we please get back to the question of chartering DKIM?

	Tony Hansen
	[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 02 Jan 2006 09:32:19 -0800

> Can we please get back to the question of chartering DKIM?

The concern raised was not specifically in regard to the base DKIM
draft.  There was concern with respect to the use of authorization in
conjunction with DKIM.  DKIM considered independent of the email-
addresses does not not have the same potential for disruption.

This is not true with SSP:

1) Authorization has great potential to disrupt normal email practices.

2) Authorization is not likely to reduced the levels of fraud, but
   rather changes tactics.

3) Misuse of authorization as authentication works to the benefit of
   large domains or those with private restrictive servers.

4) Authorization shifts the burden of reputation onto the email-domain
   owner, and may lead to a poorer systemic solutions.

5) Indications of an authorization to the recipient places them in
   greater peril of being defrauded.

The base DKIM draft does not directly introduce these problems.  When
used in conjunction with a recognition scheme (upon which expectations
can be based), far greater protection are provided without these
significant drawbacks caused by an authorization scheme.  This approach
also imposes significantly less overhead.

Include the base DKIM draft in the charter, but with the SSP draft
excluded.  DKIM permits many avenues for use.  Perhaps one way to look
at the DKIM signature is that it provides an alternative identifier to
that of the remote IP address that would be more stable as a source
identifier.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jan 2006 11:45:41 -0800

Harald,

> I seem to have managed to provoke you to anger.

Not at all.  Were you trying to?

> attempting to address their substance,

Interesting assessment.  Your assertions lacked substance and relevance and my 
comments addressed exactly those failings.

I made a point of being extremely precise about the nature and basis for the 
criticisms.

It is frankly astonishing that you have so completely missed this.

It is unfortunate that you seem to take such criticism as meaning someone is 
angry with you.

  and attempting to chastise me for
> my logic while failing to apply any standards of rigor to your own, have 
> managed to provoke me.

Here, again, you make an assertion without bothering to offer an explanation for 
its basis.

(Given that I made a point of attempting that rigor and feel relatively 
confident I succeeded, it is not surprising that you refrain from justifying 
your accusation.)

Feel free to remedy that, such as by citing what statements lack the necessary 
rigor.

> Until further notice, I will not respond further to any statement you 
> make in the IETF.

But you won't refrain from posting this inflammatory declaration publicly?

How very constructive of you.

Come to think of it, your note has the qualities of being an ad hominem attack...

d/

-- 

Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jan 2006 15:11:48 -0500

--On Sunday, 01 January, 2006 19:20 -0800 Dave Crocker
<[email-masked]> wrote:

>> DKIM has much more serious problems about applicability and
>> the definition of the problems being solved than whether or
>> not this is required.
> 
> John,
> 
> Unfortunately what you appear to be saying is that you are
> certain of serious problems, and  are happy to assert them as
> a barrier to progress -- after all, you want to insist that a
> requirement for dealing with your fears be included as a
> chartered deliverable -- but you do not feel compelled to
> provide a solid basis for these fears.
> 
> Before imposing requirements on an IETF effort, one should
> make a pragmatic case for it.  At base, the case you have so
> far made is that the reasonable mechanism of DKIM might get
> mis-used, just as any other reasonable mechanism might be.

Dave, 

We seem to have reached a fundamental disconnect about how we
think consensus decisions are reached in the IETF and, for that
matter, in other situations. I'm going to try to avoid
characterizing your position, or even what it looks like to me,
because you could quite legitimately complain that I had no way
to understand your internal thought processes.  But I can, and I
think should, explain mine.

I think we find consensus around the IETF by giving plausible
objections the benefit of the doubt and trying to find middle
grounds to accommodate them.  If we can't do so, then we can't.
Then we need to figure out how "rough" a consensus we are
willing to tolerate and either move forward or give up.  I don't
believe we have ever turned "winning by exhaustion" or "winning
by intimidation" into virtues, even though those techniques are
sometimes demonstrably effective.  I also believe it is far more
useful to the IETF for us to struggle, together, to find,
understand, and, if appropriate, adjust to, a sincere concern or
objection, rather than to simply attack either the objection or
the objector.

We have both seen, and I believe we have both objected to,
situations in which a WG has said, in essence, "you approved our
charter, and we have done all this work, so you are obligated to
approve our result".  I don't like seeing the IETF get into that
position and have proposed remedies for it --including quicker
chartering, aggressive monitoring, and rapid termination of
groups that have gotten off course-- but those ideas haven't
gotten very much traction.  So we live with what we have, which
is the notion that conditions that should be imposed on a WG
(along with special freedoms that are to be given to it) must be
in the charter.

Now this proposed WG has asked for something exceptional, which
is the right to confine its discussions to a particular range of
alternatives determined by a self-selected design team (no
matter how much that design team consists of experienced IETF
folks and has asked for review within the broader IETF
community, the decision-making to this point remains vested in
that closed design team).  I think that the use of the design
team to develop a competent and consistent proposal is a
wonderful idea but, when the design team then shows up and says
what appears (at least to me) to be "charter the WG but confine
to working on our solution, presumably as we define it" then I
believe that the burden is on the design team to demonstrate
that approach is safe and consistent with IETF principles.  I
don't think the design team, or some of its members, get to say
"we have proposed this exceptional procedure and we are entitled
to use it unless someone can _prove_, to our satisfaction, that
it is harmful".  Your views, obviously, may differ but, to me,
the very essence of asking for an exceptional procedure is that
you justify and demonstrate the safety and appropriateness of
the exceptions, not that others be forced to prove that they are
harmful.

It seems to me that the IETF also has the right to ask a whole
range of "what problem does this solve" and, especially given
the requested constraint, "what value does an IETF WG add"
questions.  Those questions are, I believe, asked fairly
regularly of other proposed WGs although the presence of the
constraint request has caused them to be asked somewhat more
intensively this time than usual.   And, again, I suggest that
it is our precedent that the proposers of the WG need to respond
to those questions rather than saying, e.g., "unless you can
identify a technical flaw in our proposal, we are entitled to a
charter and provisions of our own choosing".  

> You keep implying that it is somehow a mysterious and big deal
> to have a voluntary, validated identity associated with
> message transit.

No, I keep "implying" (I've actually tried to be fairly
explicit) that it is not well-understood what problems this
proposed protocol solves and what operational side-effects its
deployment might cause.  If those issues were security ones, I
think there would be absolutely no doubt that explanations were
required.  But, to the extent that we understand the boundary
between "security issues" and other types of side effects, these
issues are on the other side of that line.  But the IESG has
always, at least as long as I can remember such things, had the
right to require an applicability statement for a protocol being
proposed for standardization and to require that applicability
statement cover either or both of the "what problem is being
solved?" question and the "what are the side-effects?" ones.

Those of us who believe that sort of statement should be
required of a proposed WG have three choices: 

	(i) we can ask that it be made a charter requirement, or 
	
	(ii) we can try to get into the WG and argue that it is
	a critical piece of work and that that protocol proposal
	isn't complete without it, or 
	
	(iii) we can wait until Last Call and, if the statement
	doesn't appear, argue that the protocol should not be
	approved until the A/S is provided.

Taking these in reverse order, the latter would almost certainly
be treated by the WG as the worst sort of "late surprise",
perhaps especially if it came from the community rather than,
e.g., an IESG member who had been suggesting it informally for
some time.  The second, it appears to me, could too easily be
blocked by a possibly-reasonable interpretation of the notion
that the existing documents determine the WG's scope.
Assurances by several potential participant-leaders of the WG
that such discussions would not be blocked seem to be to be
somewhat countered by aggressively-taken positions during the
charter discussions that anyone raising any procedurals issues
at all must either prove harm or demonstrate serious technical
flaws in the technical proposal.  And that leaves us with the
first option.

Again, all I'm asking for here is that the charter include
requirements for an explicit statement of the problems to which
the proposed protocol is applicable and for some analysis of the
consequences of applying it in some situations in which it is
not applicable.  If the work is worth doing, that should not be
hard.  I don't believe that it would be unreasonable for the
community to take a stronger step and require that those
statements be prepared and reach consensus pre-charter but, in
the spirit of trying to let the work go forward, I'm not asking
for that... only that the applicability materials be prepared as
part of generating a proposed standard.   If the charter draft
didn't contain an apparent request for a restriction of WG scope
to the content of the materials prepared by the design team, I
would be happy with a strong suggestion now and arguing for the
importance of the applicability materials in the WG after
chartering.  But I am concerned that the exclusion might
preclude this entire discussion.  I can't _prove_ that would
happen, but I don't believe I am under any obligation to do so,
no matter how many times you repeat that demand or its
variation: if you want this exceptional restriction in the
charter, then I believe it is your obligation to demonstrate
that it is safe and that all relevant issues will be dealt with
openly and appropriately rather than, e.g., having their
proponents shouted or verbally bludgeoned into submission.

      john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jan 2006 20:51:20 -0800

> think consensus decisions are reached in the IETF ...

John, that's not the disconnect.

> grounds to accommodate them. 

*That* is one of the major disconnects.

We have different views of the word "plausible".

I think the person raising the objection has significant responsibilities to 
make careful and precise statements, including careful and precise 
substantiation.  In other words, they need to make their case and they need to 
participate constructively in a dialogue about their concerns.

Of course, is also considered good taste for them to try to include a proposed 
fix.

I also think that "plausible" needs to be balanced against the risk of stopping 
forward progress, since there is always an infinite array of 
apparently-plausible objections one can make, if one insists on perfection.

Your use of the term seems to be wildly at variance with all of this.

>     I don't

Actually we have.

It is used with some regularity by various folk in IETF management, in lieu of 
honoring the requirements of "plausible" that I provided above.  Note the change 
that Russ is making to the charter.

>    I also believe it is far more

I believe this, too.

> Now this proposed WG has asked for something exceptional, which

I have repeatedly pointed out that the issue is far less exceptional than you 
represent it.

So far, you have never responded to those points.

> folks and has asked for review within the broader IETF

1. Although it is infrequent, there are multiple times that a group has brought 
existing technology to the IETF.  You appear intent on ignoring the pattern of 
choices made to handle such cases.  Instead you seem to insist on invoking the 
"start everything from scratch model" no matter how inappropriate and even 
destructive it might be to the technical work and the group momentum.

2. You express concern that a constrained charter might restrict choice, but 
feel no obligation to give examples of the choice.  Yet a charter is a contract 
and a contract is very much about restricting choice.

3. The "design team" for DKIM now numbers about 25 organizations. Note that this 
"design team" evolved version THREE of an effort that began with Yahoo and that 
that evolution was a full-group effort.  Again, you seem intent on ignoring this 
substantial history of evolution and community involvement.  Better still is 
that you are not proposing any other solution, merely complaining about this one.

4. Any IETF effort can benefit from random input from random folk, but it also 
can suffer from it.  The core of any serious effort has a constituency that is 
vigorously trying to solve a real problem, in a timely fashion.  A requirement 
for the IETF is to *facilitate* this work, rather than to throw up arbitrary 
barriers along the way.  Facilitation might well incur delays, when real and 
significant problems are uncovered.  But the burden of elucidating such problems 
lies with the person raising them.  You seem intent on making vague claims and 
no case to support them, regarding DKIM, and are not responding to the multiple 
people who observe that the problems you cite either do not exist or exist in a 
broad class of technologies that have already been standardized.

4. It has been fascinating to watch some folks attack the DKIM effort with false 
claims that DKIM folk (e.g., me) are unwilling to accept any criticisms or 
variations.  This is so grossly untrue that the assertion seems to require 
willfully pretending that the real record of open-participation DKIM discussions 
on its mailing list does not exist.

> that closed design team). 

Wow.

You really have not tracked any of the work done on the open mailing list, have you?

>     when the design team then shows up and says

An industry group brings existing technology to the IETF and seeks to have it 
evolved and standardized in the IETF.

Pursuing other solutions might well be a good and appropriate thing to do, but 
it has nothing to do with evolving an existing technology.  Again, you seem 
unable to make the distinction, even though there is plenty of precedent in the 
IETF.

If you want to pursue other solutions, then by all means do.  But please do not 
insist that a coherent and active constituency that is seeking to evolve an 
existing solution be coerced into your (different) effort.

If in fact, you think that DKIM should not be pursued by the IETF, then please 
say so and develop community support for rejecting it.  I'm sure the 
constituency of folk working on DKIM will be quite willing to pursue the work 
elsewhere.

>  Your views, obviously, may differ but, to me,

Apparently you have not looked at the DKIM spec or the comments from others 
about it.

DKIM uses a collection of extremely well-understood techniques.  The amount of 
real innovation, involving core bits of mechanism, are somewhere between few and 
nil.  DKIM's innovation is in assembling these pieces into a useful whole.

Perhaps you have noticed that a number of other folk -- who happen to have 
little or nothing to do with DKIM -- have also taken exception to your peculiar 
fears about DKIM.

Feel free to respond to their specifics, even if you are not willing to respond 
to mine.

> the requested constraint, "what value does an IETF WG add"

What part of "I agreed that the original threats analysis work was needed" did 
you not understand?

> regularly of other proposed WGs although the presence of the

Please point out the other working groups that have been required to produce a 
threat analysis before being chartered.

> charter and provisions of our own choosing".  

Please stop raising entirely false claims, John.

Please try to include at least a modicum of reality in your claims.

What you have just described here simply never happened.

> deployment might cause. 

Since the threat analysis document addresses your first concern, you must 
disagree with its contents.  Please provide an explanation.

Since DKIM uses components of technology that are extremely well-understood, and 
since the few usage variations that the DKIM "service" might produce have been 
discussed extensively on the open mailing list, you appear to be unsatisfied 
with results.  Please provide an explanation.

> the proposed protocol is applicable and for some analysis of the

1. That's not what you have been asking for.

2. Why are you not satisfied with the threat analysis document?

d/
-- 

Dave Crocker

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Jan 2006 00:59:29 -0500

On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker 
<[email-masked]> wrote:

> It is used with some regularity by various folk in IETF management, in
> lieu of honoring the requirements of "plausible" that I provided above.

If that's true (and I'm not expressing any opinion as to whether it is), 
that doesn't make it a virtue.

> Note the change that Russ is making to the charter.

I think a lot of people might be missing a key point about how our process 
works.  In fact, it's looked that way to me for a while, and so since you 
bring it up, I'll try to clear things up for anyone who might be confused. 
Please don't think I'm singling you out...

RFC2418 says:

   The formation of a working group requires a charter which is
   primarily negotiated between a prospective working group Chair and
   the relevant Area Director(s), although final approval is made by the
   IESG with advice from the Internet Architecture Board (IAB).  A
   charter is a contract between a working group and the IETF to perform
   a set of tasks.

According to my reading of that document, it is up to the IESG whether to 
approve a charter, and with what language.  Announcement to ietf-announce 
and new-work is required; discussion on the IETF list is not.  The content 
of a charter is determined by the IESG, not by a consensus of the group 
wishing to be chartered.

In other words, Russ is within his rights to make changes to the charter he 
is willing to bring to the IESG -- especially in a case such as this where 
the proposed charter has been discussed so publicly that the rest of the 
IESG cannot possibly be deceived into thinking the charter Russ brings them 
is exactly the one the DKIM proponents proposed.

This ability to determine what work will be done and under what terms is a 
fundamental part of what it means to "steer"; without it, the IESG would 
not be much of a "steering group".

In this case, particularly given the comments I've seen from a number of 
DKIM's proponents, I feel it is appropriate to constrain the group to 
produce a specification for attempting to address a particular aspect of 
the spam problem using a particular approach.  It's beneficial to apply 
constraints like only considering solutions with domain-level granularity, 
or only addressing how to _provide_ identity information and not what to do 
with it.  Particularly given the IETF's previous experience with attempted 
anti-spam work, I think such constraints are necessary to narrow the 
problem space to one for which a working group will produce something in a 
finite time.

Besides being necessary, those constraints are also acceptable because 
while they limit _this_ working group to solving one piece of the problem, 
there is no implication that other working groups will not be chartered to 
work on other pieces.  And, while _this_ working group is constrained to a 
particular approach, there is no implication that other approaches might 
not also be tried.  In fact, there seems to be the idea that multiple 
approaches could be deployed simultaneously, that doing so would likely be 
beneficial rather than harmful, and that developing one approach is likely 
to enable or at least benefit work on other parts of the problem.

So far, so good, I think.  I'm assuming you agree with me that constraints 
such as the one I've described are reasonable; please let me know if that's 
incorrect.

What I do _not_ think is reasonable is a demand that the working group be 
constrained to produce exactly the protocol proposed, making changes only 
if absolutely necessary.  If it is to produce a standards-track-quality 
protocol, the working group must have the freedom to correct flaws it 
identifies and to make improvements, even if not "absolutely necessary". 
Of course, it is reasonable to instruct the working group to start with an 
existing proposal.  It's reasonable to require it to maintain 
interoperability with an existing standard, or even to exclude changes to 
an existing standard from its scope.  But even that must be done with care; 
often a good solution involves an extension to one or more existing 
protocols.

Note that the XMPP case is somewhat different from this one.  In that case, 
a working group was formed to "adopt" an existing technology from another 
process, and develop an Internet standard.  High value was placed on 
compatibility with the existing widely-deployed protocol, which is 
appropriate and the same treatment we'd give to our own existing standards, 
or expect other SDO's to give them.

As I understand it, DKIM is _not_ a widely-deployed protocol developed by 
another SDO; it is a proposal developed by a design team with the specific 
intent of bringing it to the IETF.  There is absolutely nothing wrong with 
that approach.  However, the normal next step is to bring the design team 
output back to a working group, or to the IETF as a whole, and ask for 
comments and/or consensus to use the design team's output as input to the 
next step in the process.

In this case, it appears that instead of doing that, the design team is 
asking the _IESG_ to make the decision that the design team's work will be 
used for the next step in the process, without the benefit of working group 
or unconstrained consensus.  I must confess that I find that behavior 
shocking, given how bitterly some of the people involved have complained 
about IETF management rushing things through without benefit of community 
consensus.

Is there some concern among the proponents of this working group that 
without a tight constraint to make only minimal changes to the proposal, 
the WG will throw it away and start over from scratch?  I understand that 
doing so would be a huge waste of time, but given constraints on both the 
scope of the problem and the range of solutions, why is a tighter 
constraint necessary to prevent the disaster?

Dave, I confess I haven't read to the end of your message, but it's getting 
late and I'd like to get up _before_ noon, for a change.  Tomorrow I will 
finish reading, and perhaps comment on the rest...

-- Jeff

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jan 2006 10:21:23 +0000

Jeffrey Hutzelman wrote:
> I think a lot of people might be missing a key point about how our 
> process works.  In fact, it's looked that way to me for a while, and so 
> since you bring it up, I'll try to clear things up for anyone who might 
> be confused. Please don't think I'm singling you out...
[...]
> In other words, Russ is within his rights to make changes to the charter 
> he is willing to bring to the IESG -- especially in a case such as this 
> where the proposed charter has been discussed so publicly that the rest 
> of the IESG cannot possibly be deceived into thinking the charter Russ 
> brings them is exactly the one the DKIM proponents proposed.

I agree. As I believe do a number of other dkim "proponents", most
of whom are, I'd say, much less concerned about these (IMO mainly
process-nit) issues with the charter text and who'd like to get on
with the work in a working group with all that that entails - most
especially including establishing wg-consensus on the text of the
chartered deliverables.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Jan 2006 10:13:14 -0800

Jeffrey,

(I have changed the subject line, so that this discussion is explicitly NOT 
about any current IETF chartering activities.  I hope folks will not take my 
comments as having any implication about any of those efforts or discussions 
about them...)

> process works.  

What makes things particularly challenging is the difference between Procrustean 
  attention to documented rules, versus applying them in an integrated manner 
with subjective assessment of the pragmatics of being productive.  Any 
organization that strictly resolves disputes based on the letter of its laws 
quickly alienates is workforce.

When we wrote the rules regarding chartering, the intent was to have the 
cognizant AD conduct whatever discussion were needed to create a working group 
that would be productive.  This is inherently a fuzzy process, so it was -- and 
remains -- important to avoid over-documenting the procedure.

For example, an AD who entirely ignores the concerns and desires of those who 
will do the bulk of the work risks having a working group without workers.

The pragmatics, therefore, require the AD to try to juggle various political, 
technical and project management concerns, and put forward a charter that they 
feel will offer the best chance at productive working group output.

Frequently -- maybe usually -- this is primarily through a private dialogue 
among those who will form the small core of the working group effort, including 
likely chairs.  However it is not uncommon for a public dialogue to be 
conducted.  For example, a BOF usually includes a review of candidate charter 
text.  That the open group's consensus is not binding on the AD merely indicates 
the delicate nature of chartering, rather than the irrelevance of that consensus.

> This ability to determine what work will be done and under what terms is 
> a fundamental part of what it means to "steer"; without it, the IESG 
> would not be much of a "steering group".

Actually, this highlights why "steering group" is exactly the wrong term for the 
IETF process management team.  They do not initiate work and they are not 
primary contributors to that work.  Hence, they do not really "steer" anything. 
  When the IESG tries to act like it does, they often find no workers and a mass 
of dissatsfaction.

The job of the IESG is to facilitate the initiatives of others and to ensure 
enforcement of useful quality assurance.

>     It's beneficial to apply 
> constraints like only considering solutions with domain-level 
> granularity, or only addressing how to _provide_ identity information 
> and not what to do with it.  Particularly given the IETF's previous 
> experience with attempted anti-spam work, I think such constraints are 
> necessary to narrow the problem space to one for which a working group 
> will produce something in a finite time.
> 
> while they limit _this_ working group to solving one piece of the 
> problem, there is no implication that other working groups will not be 
> chartered to work on other pieces.  And, while _this_ working group is 
> constrained to a particular approach, there is no implication that other 
> approaches might not also be tried.  

all of the above is nicely said, as comments about a class of working group 
startup efforts.

> What I do _not_ think is reasonable is a demand that the working group 
> be constrained to produce exactly the protocol proposed, making changes 
> only if absolutely necessary.  

And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an idea. 
Some with a detailed proposal.  Some with a detailed specification and some with 
existing and deployed technology.  When a working group starts, it must make the 
strategic decision about how much prior work to preserve, versus how much new 
work to encourage or require.

There are obvious and significant trade-offs in this choice.  What is essential 
is that the trade-offs get serious consideration and that the choice be 
appropriate to the particular situation.  It absolutely is NOT true that all 
chartered working groups must be allowed to throw away any and all prior work. 
The loss of invested community effort and the loss of momentum would be disastrous.

At the least, an effort that seeks to use existing technology needs to explain 
clearly and convincingly what needs to be preserved.  Equally, any efforts to 
deny the stability of re-using that work must make a compelling and concrete 
case for the changes that are needed.

> Note that the XMPP case is somewhat different from this one.

Remembering that this new thread is about a general issue, rather than debating 
a particular working group effort, I'll comment on the particulars of your 
reference:

   In that
> case, a working group was formed to "adopt" an existing technology from 
> another process, and develop an Internet standard.  High value was 
> placed on compatibility with the existing widely-deployed protocol, 
> which is appropriate and the same treatment we'd give to our own 
> existing standards, or expect other SDO's to give them.
> 
> As I understand it, DKIM is _not_ a widely-deployed protocol developed 
> by another SDO; it is a proposal developed by a design team with the 
> specific intent of bringing it to the IETF.  There is absolutely nothing 
> wrong with that approach.  However, the normal next step is to bring the 
> design team output back to a working group, or to the IETF as a whole, 
> and ask for comments and/or consensus to use the design team's output as 
> input to the next step in the process.

Jabber did not come from another SDO.  Even if it had, I fail to see why that 
imparts special status.  DKIM came from a substantial -- albeit informal -- 
industry initiative with quite a few organizations participating. Nothing about 
Jabber's or DKIM's origins automatically make the technical quality of the work 
good or bad, or necessarily of interest to the IETF.

(Well, ok, I'll indulge in a particular, in order to correct a factual error: 
Mis-statements about DKIM's deployed base have been corrected quite a few times. 
  Suffice it to say that your understanding is incorrect.)

> asking the _IESG_ to make the decision that the design team's work will 
> be used for the next step in the process, without the benefit of working 
> group or unconstrained consensus. 

(Damn.  Have to correct another one:  I have been boringly pedantic about citing 
the TWO rounds of OPEN, online consensus effort surrounding the draft charter. 
This was not a tiny cabal or even a larger, albeit closed, group or 
organizations.  The draft charter text was produced by a highly open and 
responsive process over the course of months.)

d/
-- 

Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 07:12:40 -0500

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> John K., et al, Feliz año nuevo; Selamat tahun baru.

    >> I do believe that it is not desirable to create standards that
    >> would give a gift of either technology or justification to
    >> those who would use them to fragment the network.  I believe it
    >> is especially

    Dave> I suspect we will not find anyone in the IETF who thinks
    Dave> otherwise.  Certainly my own reaction to your statement,
    Dave> here, was "Yes!!  Absolutely Correct!"

    Dave> Then I tried to consider the implications of the statement,
    Dave> in the current context, and I realized that I have no idea
    Dave> what pragmatic import it has.

    Dave> I have no idea how to apply this caveat to the DKIM work.

    Dave> DKIM is DKIM. As a technology it has a specific intent and
    Dave> its core is well-defined -- and actually pretty simple --
    Dave> with well-understood properties. The core is similar to a
    Dave> number of technologies that have been in use for at least 15
    Dave> years.

I think John is expressing a concern similar to the one I expressed at
the BOF.

Roughly we need to consider how DKIM is used, not just define a
technology.  We need to talk about bad uses of DKIM as soon as we are
aware that they are sufficinetly likely that they are worth
considering.

We need to write BCPs as soon as we are in a position to know what
best practice actually is.

Now, other than acknowledging that we need to eventually do these
things, I don't think this has any impact on the charter.  On the
other hand, John replied to a message about three levels removed from
the charter and proposed no specific changes to the charter.  So I
don't have any evidence that he planned to change the charter either.

--Sam

---

From: John Levine <[email-masked]>
Date: 4 Jan 2006 13:51:33 -0000

> technology.  We need to talk about bad uses of DKIM as soon as we
> are aware that they are sufficinetly likely that they are worth
> considering.

Here's a concrete suggestion: it is clear that the bad uses of DKIM
people have mentioned are a subset of the bad uses of STARTTLS.

I have seen concerns that third party reputation lists might be used
to create walled gardens or closed networks with DKIM.  This is not
just a theoretical risk with STARTTLS.  People have already done
exactly that, since TLS unlike DKIM already includes the facilities
for third parties to indicate which keys they like and which ones they
don't.  And the TLS world is dominated by a single signer whose
signing policies are opaque.

So how about if we simply reuse the warning language about STARTTLS
from RFC 3207?  If that's not adequate, do we need to write similar
warnings about STARTTLS?

R's,
John

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 09:54:56 -0500

>>>>> "John" == John Levine <[email-masked]> writes:

    >> technology.  We need to talk about bad uses of DKIM as soon as
    >> we are aware that they are sufficinetly likely that they are
    >> worth considering.

    John> Here's a concrete suggestion: it is clear that the bad uses
    John> of DKIM people have mentioned are a subset of the bad uses
    John> of STARTTLS.

That's not clear to me.
I'd never really considered the question though so it may well be true.

    John> I have seen concerns that third party reputation lists might
    John> be used to create walled gardens or closed networks with
    John> DKIM.  This is not just a theoretical risk with STARTTLS.
    John> People have already done exactly that, since TLS unlike DKIM
    John> already includes the facilities for third parties to
    John> indicate which keys they like and which ones they don't.

Interesting I'll admit that I have not run into people who seem to
have a problem with a self-signed starttls cert in practice, although
I might not have noticed.  Also, I don't configure MTAs or my MUA to
offer a client cert, only a server cert.

I agree it is possible and am happy to take your word for it that someone has done so.

    John> And the TLS world is dominated by a single signer whose
    John> signing policies are opaque.

Really?  Are you sure the TLS world is not dominated by users clicking
OK trust this cert for anything they see, combined with a lot of self
signed certs and certs from a variety of CAs?  I do expect that most
web sites tend to have Verisign certs, but I have no idea about other
uses of TLS.

    John> So how about if we simply reuse the warning language about
    John> STARTTLS from RFC 3207?  

What warning language?  I can't find anything related to this problem.
I may not be looking carefully enough.

    John> If that's not adequate, do we need
    John> to write similar warnings about STARTTLS?

Quite possibly.

--Sam

---

From: "John R Levine" <[email-masked]>
Date: 4 Jan 2006 10:27:16 -0500

> I'd never really considered the question though so it may well be true.

If walled gardens are the problem or the goal, STARTTLS is a swell way to
do it.

> signed certs and certs from a variety of CAs?

The CAs that people use in web SSL are overwhelmingly signed by Verisign
or its subsidiaries like Thawte.  Geotrust is a distant second.

I honestly don't know what signers people use for STARTTLS but since
everyone uses the same small set of TLS libraries, my working assumption
is that they use the same small set of authorities, too.

> I may not be looking carefully enough.

There isn't any.  That's my point.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 10:30:07 -0500

>>>>> "John" == John R Levine <[email-masked]> writes:

    John> The CAs that people use in web SSL are overwhelmingly signed
    John> by Verisign or its subsidiaries like Thawte.  Geotrust is a
    John> distant second.

    John> I honestly don't know what signers people use for STARTTLS
    John> but since everyone uses the same small set of TLS libraries,
    John> my working assumption is that they use the same small set of
    John> authorities, too.

OK.  If this is just an assumption and not backed by evidence, I would
suspect that outside of the web you see a lot less use of the big CAs.

---

From: "John R Levine" <[email-masked]>
Date: 4 Jan 2006 10:32:41 -0500

> suspect that outside of the web you see a lot less use of the big CAs.

Probably true.  And since DKIM has no provision for authorities at all, it
definitely doesn't use them.

So remind me, what is the problem with DKIM that we're all supposed to be
worried about?

Regards,

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jan 2006 16:45:18 +0100

> web sites tend to have Verisign certs, but I have no idea about other

Here's an interesting thing you can do if you're an Opera user:

Go into the preferences/advanced/security section and mark all your root 
certs as "warn me before I use this cert".
Then Opera will tell you which root cert the website got its cert from 
every time you click on a HTTPS link.

If most of the Net uses Verisign, Verisign's got a bewildering array of 
names....

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Jan 2006 15:43:55 +0000

> suspect that outside of the web you see a lot less use of the big CAs.

Web-style TLS is used for authenticating the server in other protocols
too, such as IMAP, submission-mode SMTP, XMPP, etc. etc. and in all these
cases it is extremely desirable not to have to set up a local CA because
the user interface for configuring client software is so bad.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 04 Jan 2006 08:14:05 -0800

>> suspect that outside of the web you see a lot less use of the big CAs.

This is my impression as well. And a fair amount of the reason here
is UI: the browsers are set up to check the server's cert and
the MTAs generally are not.

> definitely doesn't use them.

Well, yes and no. DKIM depends for its security on the DNS,
which means that it depends on the security of the DNS.
In order for this to be strong (i.e., cryptographic) security,
the relevant DNS records need to be signed and that means 
that there's a dependency on the DNSSEC roots.

> So remind me, what is the problem with DKIM that we're all supposed to be

AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be concerned
about, indeed, the logic of this kind of system is that if it succeeds
that's exactly what will happen. 

That said, I don't think that the comparison with STARTTLS is particularly
illuminating. While in principle one could use STARTTLS as a measure
to discriminate between classes of senders, in practice it's not used
that way but instead used primarily for confidentiality. However,
DKIM's only real use is to discriminate between classes of senders,
so we do need to expect it to be used that way.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Jan 2006 09:59:58 -0800

E> AS I understand it the concern is that people who don't use DKIM
> that's exactly what will happen. 

Interesting.

I have not heard any DKIM proponent use that logic.

I have, however, heard critics fail to understand the difference between

    a) special handling of "good" identities, versus continuing to have 
suspicious handling of "unknown" identities, and

    b) acceptance of good addresses and rejection of unknown.

Proponents seek to use DKIM for a), not b).

Critics keep asserting that b) is the only avenue that is possible.

So, they are wrong that it is the intent and they have no empirical basis for 
asserting that it is certain or even likely to occur.

d/

-- 

Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 04 Jan 2006 10:43:27 -0800

> I have not heard any DKIM proponent use that logic.

Maybe not, but I think that it's the likely endgame.

>     a) special handling of "good" identities, versus continuing to
>     have suspicious handling of "unknown" identities, and
>
> So, they are wrong that it is the intent and they have no empirical
> basis for asserting that it is certain or even likely to occur.

No, I don't have any empirical evidence for asserting that it's
certain or likely to occur. But in truth nobody has much empirical
evidence for anything here, so we're reduced to theorizing.

Now that we've got that out of the way, it's worth working through the
reasoning of why I think (b) is the likely endgame.  

The basic value proposition of any sender authentication system as an
input to filtering is that lets you increase the sensitivity of the
filters, while still obtaining an acceptable overall false positive
rate. Imagine that without sender auth, your filters have a false
positive rate of P and a false negative rate of N. With sender auth,
some fraction of those false positives will be eliminated, letting you
dial up the sensitivity of the filter. If we assume that the sender
authentication is perfect, then we get the following:

                      Message 
                      Authenticated
                 
                      Yes           No    
False positive        0             P' (P' > P)  
False negatives       0             N' (N' < N)

But this makes it even more attractive for the good senders to
authenticate their messages (because otherwise they stand a higher
chance of being rejected) which means that the receivers can increase
the sensitivity of their filters, and so on.  So, at the end of the
day, if something like DKIM is successful, I would expect an
equilibrium where filters are set extremely high and nearly all good
senders authenticate their messages because otherwise they stand
an unacceptably high chance of having them rejected.

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jan 2006 10:46:13 -0800

On Jan 4, 2006, at 9:59 AM, Dave Crocker wrote:

>> it. I'm not sure that this is something that people should be  
>> concerned about, indeed, the logic of this kind of system is that  
>> if it succeeds that's exactly what will happen.
>
>
> Interesting.
>

The current proposed charter includes both the DKIM signature element  
that indeed provides a stable identifier.  No additional problem  
should be created as a result of this more stable identifier of which  
I can foresee.

There is also a proposal to introduce an email-address authorization  
scheme that transposes the Sender-ID email-addresses with signatures  
and uses a far more disruptive From header rather than the less  
disruptive PRA.  Will there be a PRA proposal for the SSP header  
selection soon?

The concern with this authorization scheme is that many email-address  
domains will likely be coerced into publishing some form of  
authorization to mitigate the high overhead otherwise imposed by the  
scheme.  The next possible point of coercion would be to restrict  
authorization to a limited set of signatures which dramatically  
alters current practices and is inherently unfair.  In general, when  
this authorization is used to accrue reputation as was done with  
Sender-ID, this imposes an unfair and highly disruptive element into  
how email functions.

> Proponents seek to use DKIM for a), not b).

This mischaracterizes the concern raised significantly.

> Critics keep asserting that b) is the only avenue that is possible.

Reputation based upon some identifier is already ubiquitously used to  
block abusive email.  A stronger method of identification does not  
increase any concern related to 'b' except when applied to the SSP  
authorization instead of the signature.  Even the SSP draft holds the  
email-address domain that provided the authorization accountable by  
way of complaints.  The authorization scheme introduces a weaker and  
unfair method of identification.

> basis for asserting that it is certain or even likely to occur.

There has already been a scheme implemented a major vender that uses  
authorization as suggested.  A minor tweak to widely deploy system  
and instant problem.

-Doug

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 04 Jan 2006 11:38:19 -0800

Dave Crocker <[email-masked]> writes:
>> rate.
> Nicely said.  (And, by the way, I agree with the statement.)
>
>
>   Imagine that without sender auth, your filters have a false
>>                       Message                       Authenticated
>>                                        Yes           No    False
>> positive        0             P' (P' > P)  False negatives       0
>> N' (N' < N)
> I am less certain of "expect" than I am of "hope for".
>
> In any event, that is quite different from *requiring* everyone to
> sign, or automatically rejecting all unsigned mail.  Yet these are
> what you were putting forward.

I don't know what you mean by "putting forward". Here's what I wrote:

I guess it depends on how significant you think the difference between
"automatically rejecting all unsigned e-mail" and "unacceptably high
chance of having them rejected" is. My view is that it's more a
difference of degree than kind, but I apologize for speaking
imprecisely.

> Further as was pointed out at the BOF, the scenario you have describe
> is a voluntary community collaboration.  So if the outcome you
> describe occurs, it will be because the community agrees that they
> like that outcome.
>
> This makes it really perplexing to view it as a problem.

And I didn't say it was a problem. Indeed, I said "I'm not sure that
this is something that people should be concerned about..."

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Jan 2006 10:58:32 -0800

Eric,

> evidence for anything here, so we're reduced to theorizing.

Serious theorizing works carefully from an empirical base, with a clear logic 
sequence.  This never guarantees that they are correct, but does serve to vet 
their legitimacy.

Theorizing absent this kind of effort is not theorizing.  It is fantasizing.

There are an infinite number of possible fantasies and their injection into a 
project management effort, such as the start of a standards process, mostly -- I 
even suspect exclusively -- serves as distraction, particularly when they are 
repeated forcefully.

> reasoning of why I think (b) is the likely endgame.  

It certainly is.

In any event, that is quite different from *requiring* everyone to sign, or 
automatically rejecting all unsigned mail.  Yet these are what you were putting 
forward.

Further as was pointed out at the BOF, the scenario you have describe is a 
voluntary community collaboration.  So if the outcome you describe occurs, it 
will be because the community agrees that they like that outcome.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2006 11:49:26 -0800

[]

Sigh. Can I suggest that a little exponential backoff on
all parts may be appropriate? As one of the authors of the
dkim draft, this has been an extremely painful thread to
watch.

		Mike

---

From: John Levine <[email-masked]>
Date: 4 Jan 2006 20:48:23 -0000

> if something like DKIM is successful, I would expect an equilibrium
> where filters are set extremely high and nearly all good senders
> authenticate their messages because otherwise they stand an
> unacceptably high chance of having them rejected.

That seems plausible at some point, maybe five years or more from now,
if DKIM catches on and something doesn't blindside us from left field
in the meantime.

Does anyone consider it to be a problem?

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jan 2006 14:08:15 +0100

> dkim draft, this has been an extremely painful thread to

Correct. This is way beyond the point of being productive
and beyond the point where busy people will even read 5%
of the messages.

     Brian