Re: bozoproofing the net, was The Value of Reputation

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 
<dhc2(_at_)dcrocker(_dot_)net> wrote:
> > 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.
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").
> 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.
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).
>  > - 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?
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.
> > 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?
> and perhaps because they are not consensus statements.
>
> 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.
>
> When did fear and psychosocial guesses become the basis for blocking IETF
> standards efforts?
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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf