Re: bozoproofing the net, was The Value of Reputation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]