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:This is a dramatic over-simplification.
> 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
That's your subjective opinion, and I think it's wrong.
> and the deployedTLS yes,
> network is shifting with some pace toward this being mandatory.
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.
This is also a dramatic over-simplification. SNI support is easy,
> The only additional issue for SMTP is that you'd need SNI, but that's not
> terribly onerous these days.
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.