Subject: Re: bozo-proofing the net (or making better bozos?)

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Jan 2006 11:38:40 -0800 (PST)

Can we also conclude that SSL/TLS has failed as a tool for general 
communication?  

I think the issue here is whether we're talking about user-machine or 
machine-machine interaction.  When I bring up an https:// URL, very often 
I will encounter a cert-related error.  The certificate will be expired, 
or the altSubjectName may not match the name of the site, or it may not 
have a path to a pre-established trust anchor.  

If SSL/TLS is being used as a machine-machine security mechanism, these 
errors will often be fatal, implying the need for pre-configuration in 
order to ensure reliable operation.  SMTP over TLS is an example of a 
situation where pre-configuration is typically required. 

On the other hand, when user-machine interaction is occurring, the user 
may be given the opportunity to remedy the situation.  We can argue about 
whether this is likely to be effective (how many users have the expertise 
to really understand whether they should click "OK" or not?) but the point 
is that without a user bypass, general use of https would be difficult. 

The question in my mind is where DKIM fits in this continuum.  As long 
as the user is given the opportunity to look at the "spam" bucket, to see 
if anything important was mistakenly placed there, it seems more akin to 
the https:// case, than the S/MIME case.  The situation would be 
different, for example, if the technology were to be used to prevent mail 
delivery at all (e.g. mandatory use of SMTP over TLS with mutual 
authentication).  In that situation, the balkanization of trust 
hierarchies would prove highly disruptive. 

Harald Alvestrand said:

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....

John Levine said:

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.

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

---

From: John Levine <[email-masked]>
Date: 2 Jan 2006 21:34:06 -0000

>Can we also conclude that SSL/TLS has failed as a tool for general

If we were holding it to the same requirements that some appear to be
asking for DKIM, I think we'd have to.

There is a certain amount of SMTP over TLS, an entirely automated
application, and the net hasn't collapsed.  I experimented with it for
a while before concluding that I didn't care about the threats against
which it defends, and was surprised how many SMTP hosts do TLS when
given the chance.

People have figured out reasonable ways to deal with TLS errors,
ranging from dropping the connection if it's suppposed to be part of a
private mail network to logging and ignoring the errors if it's
regular mail.  If they set up their regular mail servers to drop
connections on TLS failures, they'd lose a lot of mail.  So they
don't.

I don't see any reason to assume that mail admins will be any worse at
dealing with DKIM errors than they are with TLS errors.

>or is less dangerous like the other three and doesn't.

R's,
John

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Jan 2006 16:01:16 -0800 (PST)

> asking for DKIM, I think we'd have to.

Right.

> application, and the net hasn't collapsed.  

I don't see why DKIM is inherently different either.  If ISPs were looking 
for an excuse to not accept mail from unknown sources, they could use SMTP 
over TLS and a customized set of trust anchors to achieve that aim, 
without requiring any new protocols.  They didn't. 

> >dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.

Don't hold your breath.