Re: SMTP authentication (not soon)

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

 



On 10 July 2014 09:53, 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.


That's your subjective opinion, and I think it's wrong.
 
> and the deployed
> network is shifting with some pace toward this being mandatory.

TLS yes,

With you so far.
 
PKIX authentication, not so much,

No, there really is a serious deployed base of XMPP servers running with valid, authenticatable certificates. There are a number of servers deployed which require authentication by certificate alone, and they do just fine, unless you want to talk to XMPP service providers who don't care about interop and/or security (like Google).
 
and only provides security
when the XMPP server can obtain certificates for the target domain
(not the SRV host).

... which is the norm, for XMPP. However your statement is somewhat incorrect; if DNSSEC is deployed and the SRV/MX RR is secured, the hostname can be used as a reference name just fine. No loss of security.

DNSSEC deployment is on the rise within the XMPP world, though support isn't yet well implemented.
 
With SMTP third-party MX hosting is rather common,
and makes the latter substantially more difficult.

Here I tend to agree, however that doesn't mean that the whole of PKIX is a lost cause. Not only is there the DNSSEC option as described briefly above, but service-restricted certificates (using sRVName, for example) should mitigate much of the concerns anyway. It's unfortunate that the CA industry seems to assume that any use of Subject Alternate Names is a premium service that should be charged at ten times the rate, of course.

I'd note that these concerns exist, albeit to a generally reduced degree, within the XMPP world.

Mind you, they also exist in the HTTP world, but for some reason I cannot fathom, everyone appears to tacitly ignore them there.
 

> The only additional issue for SMTP is that you'd need SNI, but that's not
> terribly onerous these days.

This is also a dramatic over-simplification.  SNI support is easy,
cross-domain key management is not, and other barriers remain.
Since this is a distraction, I will not debate it further point by
point.

I don't think it's much of a simplification at all - the differences are of degree, not form.

The major barrier that exists is in the required global uplift in security - the XMPP community is rather smaller, and more tight-knit than the mail community. But this problem exists for purely DANE-based solutions as well.

Dave.

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