--On Tuesday, November 10, 2015 16:41 +0100 Simon Josefsson
<simon@xxxxxxxxxxxxx> wrote:
> John C Klensin <john-ietf@xxxxxxx> writes:
>
>> You may reasonably
>> claim that those criteria are almost never satisfied today and
>> that almost all TLS connections between SMTP sender and SMTP
>> receiver are made in the same casual way that almost all HTTPS
>> ones are.
>
> That is far from true -- all significant web browsers out
> there validate HTTPS certs against a pre-distributed CA
> bundle, and reject connections when that fails. SMTP servers
> in general never reject connections when cert checking fails.
> You may argue that CAs perform casual checking, but it is
> distinctly better than permitting any certificates as in the
> SMTP world.
Simon,
This is, IMO, less a matter of true or falsity but a question of
who one trusts and why. I understand that the general pattern
of SMTP servers is to not reject connections unless they can
verify the cert. However, in the web browser case, it appears
to be fairly easy (especially if money changes hands) to get a
CA into that bundle. Many CAs, including some those who
typically appear in those bundles, are willing to issue a cert
on the basis that someone appears to "own" a domain name and can
receive mail at an address in that domain. And many domain name
registrars do no identity verification at all beyond ability to
pay (and are happy to obscure much of the information).
One way to summarize our disagreement is that your last sentence
says "...distinctly better" where I would have said "...really
not much better".
A different way to look at the problem is to ask the question of
what sort of threat one is trying to protect against. If the
answer is "casual eavesdropping", then probably any cert, even a
self-signed one, will do. If the answer is "protection against
a determined attacker who has resources and is willing to invest
them", then I don't think much of certificates that involve only
casual or indifferent checking by the issuer.
YMMD and probably does.
john