Subject: [dane] On SMTP and SUBMIT

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Aug 2011 11:33:33 +0100

On Fri, Aug 12, 2011 at 4:01 AM, Mark Andrews <[email-masked]> wrote:

There is a very basic misunderstanding that some members of this WG seem to
be unable to get out of their heads, that the purpose of the group should be
to stop people using bad crypto rather than to get people to use good (or at
least better) crypto.

If the alternative is to communicate in plaintext, you can accept a
certificate minted by satan himself and you will be more secure than
communicating in plaintext.

It follows that it is only relevant to worry about the quality of a
certificate after one can establish that the security mechanism is offered.

It is of course highly desirable to get to a state where a system fails
safe. But that requires a lot more than simply telling people to reject
misconfigured crypto. It requires that there is a mechanism to explicitly
inform the counterparty that it should expect crypto. In other words it
requires a security policy mechanism.

In the browser world, the padlock icon stands for a substitute for a
security policy mechanism. That is why the matching of the domain name is
relevant. If you have DNSSEC then the whole game changes completely.

Security policy is not that hard, but it does require security policy to be
the starting point for the design. It also requires DNSSEC, in fact that was
the whole point of DNSSEC.

Security policy does not work particularly well in the DKIM world because
email is a rather peculiar system. It is the only major protocol where
messages are habitually routed through a fan out distribution (mailing
lists) that is outside the direct control of both sender and receiver.

If people want to work on certificate quality then they should first accept
that they are doing security policy and then start from the most important
criteria, whether security is going to be used at all.

Otherwise you will end up chasing an infinite series of apparent
contradictions in deployment like the ones Mark and other give.

If we were going to do that, the sensible approach would be to talk to the
email server providers and get them engaged. That is a heck of a lot easier
than getting the browser providers engaged.

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 08:18:29 -0400

> communicating in plaintext.

I think there are some (perhaps many) people who simply disagree with
you about that premise, and without that premise the rest of your
argument falls apart.

Some would argue, for instance, that it is actually _worse_ security
to use certificates to which you don't have a good trust path, because
it gives you a sense of security you might not have in communicating
in plaintext.  If the certificate comes from Moriarty and you have
accepted it and then do things that you would not have done in
plaintext, then your security situation is worse.

I think both of those situations actually obtain on the Internet
today: some people blindly accept certificates and are actually better
off because their communication is better secured than it otherwise
would be; other people are wary of such certificates and therefore
simply don't do what they would have done in the presence of a
certificate they had obtained securely (for some value of "securely").
I also think arguing about the empirical matter on this list is a
waste of time, because I haven't seen any good studies on this and I
don't even know how you'd conduct one.

In any case, I don't see how the debate is relevant.  There is a
proposed mechanism for getting a TLSA record, and the only debatable
matter relevant to this topic is whether you MUST have DNSSEC
validation in order to use that TLSA record data.  My personal opinion
is that we already have plenty of unsecured ways to bootstrap secured
communication, and so we don't need another; therefore, as a matter of
protocol I support the MUST.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Aug 2011 06:33:21 -0700

>>>>> On Fri, 12 Aug 2011 11:33:33 +0100, Phillip Hallam-Baker <[email-masked]> said:

PH> Security policy does not work particularly well in the DKIM world because
PH> email is a rather peculiar system. It is the only major protocol where
PH> messages are habitually routed through a fan out distribution (mailing
PH> lists) that is outside the direct control of both sender and
PH> receiver.

Security policy has been shown to not work well in the web world either.
I'll take "Countries who's governments install border http and https
proxies for 1000" Alex.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Aug 2011 16:47:17 +0100

> you about that premise, and without that premise the rest of your

Which is what I believed twenty years ago.

Since then we have had research into security usability that has forced me
to re-evaluate that position.

> to use certificates to which you don't have a good trust path,

Bad security would be worse than no security if people were more likely to
rely on a system because they thought it was secure. Unfortunately all the
evidence we have of real people using the Internet is that the expect it to
be secure regardless of whether cryptography is used or not.

> because
> plaintext, then your security situation is worse
>

That is why some of us want to get rid of the padlock icon completely,
including for CA issued certs.

Incidentally, we use the name Mallet because Mallory objected to the use of
his name. I would guess Kathleen would prefer you use Mallet for the same
reason.

> In any case, I don't see how the debate is relevant.

It is relevant if you are going to set criteria for name matching.

In the case of SMTP the message will be sent in plaintext if crypto is not
used and so any cert is better than none.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Aug 2011 08:59:19 -0700

<author-hat on>
If there is an issue for the TLSA protocol document in this thread, I am not seeing it, and I would really like to. Even if this is about future work for the DANE WG, making what that work will be clearer will help Jakob and I say the right things (and not say the wrong things) in the TLSA protocol document.
</author-hat>

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 12:07:39 -0400

> his name. I would guess Kathleen would prefer you use Mallet for the same

I guess I don't know Kathleen Moriarty, but where I come from the
villain Moriarty is an evil suuuuper-genius invented by Sir Arthur
Conan Doyle.  I am willing to switch to Wile E. if you prefer.  You
seemed in any case to be suggesting accepting certificates from Satan,
but I do not pretend that human crypto is going to foil the
supernatural powers of a guy whose metaphysics are impenetrable to me.
(I guess he'd just shake his magick pitch-fork, thereby unlocking the
code, getting a fiddle down in Georgia, and condemning
non-right-thinking voters in one spell.)  Professor Moriarty, however,
is supposed to be human, and I thought as a super-genius he might do.
My deepest apologies.  Let's call our villain M. and be done with it,
shall we?

> used and so any cert is better than none.

Oh, so now I understand: you're back on that hobby-horse.

The proposed rules so far exactly match the way the DNS works.  You
match the QNAME and you follow the alias records according to the
rules for those alias records.  I don't know what the problem is
supposed to be here.  If you think there is a problem, I urge you to
state it succinctly and specifically.  The last time I asked you to do
this, you responded with an argument dependent on claims about what
random people on the Internet expect from a completely new RRTYPE --
the premise of which I doubt and the conclusion of which I reject in
any case on other grounds.  I am entirely open to the possibility that
there is a problem here, but so far I haven't seen even the shred of a
plausible argument to that effect.

Other things, like what people ought to do about MX records and so on,
are just not part of this WG's problem, AFAICS.  Are you arguing
otherwise?  I can't tell.

Best,

A

-- 
Andrew Sullivan
[email-masked]