ietf
[Top] [All Lists]

Re: SMTP authentication (not soon)

2014-07-10 09:19:23
On Thu, Jul 10, 2014 at 4:53 AM, Viktor Dukhovni 
<ietf-dane(_at_)dukhovni(_dot_)org>
wrote:

On Thu, Jul 10, 2014 at 08:29:49AM +0100, Dave Cridland wrote:

On 10 July 2014 02:45, Phillip Hallam-Baker 
<phill(_at_)hallambaker(_dot_)com>
wrote:

So how can it be impractical to do something that has already been
routing
for over a decade?

Also, XMPP has almost the exact same set of problems as (MTA/MTA) SMTP,
and
seems to have deployed TLS with PKIX auth just fine

This is a dramatic over-simplification.


Not really, when you state that something is impossible then the fact that
you have ignored the fact people have being doing it for over a decade you
are the one making the 'dramatic oversimplification'.

MUA to MTA is not really as different from a trust perspective as you
imagine. The problem is the lack of a security policy infrastructure. But
that has already been added to HTTP for HTTPS with pinning and it could be
added to SMTP in the same way. To deny those possibilities with a wiff of
the hand is dramatic oversimplification.


There is a huge amount of specious anti-CA babble that goes on in this
forum and a distinct disinterest in comparing like with like. For example
lets take Heartbleed, an attack that was orders of magnitude more serious
than any CA error apart from DigiNotar. But have people concluded that we
can't trust open source software at all? There was the Apple issue that led
to a huge exposure but nobody suggested defenistrating Safari.

The CA security model I and others developed in the late 90s was always
predicated on the idea that revoked certificates would result in a
hardfail. The browser providers decided that the CA validation processes
were sufficiently strong that softfail is sufficient. But nobody seems to
want to hold them accountable for the consequences of that short cut.

I find the special pleading that goes on here to be rather irritating. Can
we please get back to (or start) making engineering decisions on an actual
engineering basis not some ideology about what the best PKI is.


Right now the WebPKI is the only one we have got and that is likely to
remain the case for quite a while, at least as far as the server side goes.
Which is a pity as DNSSEC which requires far more active management than a
PKIX certificate is potentially a major business opportunity for CAs.

I am not at all opposed to 'free' PKIs. In fact the day before Toronto
starts I will be in NYC with Ellsberg, Snowden et. al. launching a personal
PKI that does not require anyone to pay anyone to manage it.

You see at the end of the day any crypto geek worth their salt is going to
be charging $200/hr to set up a PKI and an InstantSSL cert from Comodo
costs $65 and comes with support. And its easier to find my product than
find a crypto-geek to configure a 'free' PKI. And anyone who tries to
manage free PKIs in bulk is going to build something that looks like our
operation or our competitors.
<Prev in Thread] Current Thread [Next in Thread>