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