Re: SMTP authentication (not soon)

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

 






On Thu, Jul 10, 2014 at 4:53 AM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Thu, Jul 10, 2014 at 08:29:49AM +0100, Dave Cridland wrote:

> On 10 July 2014 02:45, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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.

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