Subject: Re: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt

From: Simon Tennant <[email-masked]>
Date: Wed, 13 Feb 2013 15:02:08 +0100

I've been chatting with Florian about this the two standards for proving
ownership in the case of a delegating domain hosting.

Some background: Florian hosts many XMPP domains and at buddycloud, we're
putting plans in place to host XMPP domains. In both cases, the more we
have to ask customers to configure on their end, the less chance there is
of a successful deployment.

Right now this is:
a) customer edits their DNS and point it at our servers. Nothing else.

I have huge concerns about expecting customers to provide proofs at the web
layer. Especially something that runs on their "main" website. Some reasons
off the top of my head:
a) Messaging team is different to web team - slow or no deployment.
b) no website hosted on their domain - do we now host web stuff too?
c) their website is created or hosted by their marketing agency / some
other less technical. A simple website push could overwrite their
.well-known record could kill their messaging service.
d) it's complicated.

DNSSEC is being rolled out. Sure some registrar and TLDs will take longer
to deploy, but in the long term, I think this is the right way to have
customers (especially non-technical customers who would rather delegate
hosting) delegate their hosting.

S.

On 11 January 2013 02:57, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Just a small update to reflect publication of RFC 6698...
>
> Peter
>
> - -------- Original Message --------
> Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt
> Date: Thu, 10 Jan 2013 10:44:32 -0800
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Using DNS Security Extensions (DNSSEC) and
> DNS-based Authentication of Named Entities (DANE) as a Prooftype for
> XMPP Domain Name Associations
>         Author(s)       : Matthew Miller
>                           Peter Saint-Andre
>         Filename        : draft-miller-xmpp-dnssec-prooftype-03.txt
>         Pages           : 7
>         Date            : 2013-01-10
>
> Abstract:
>    This document defines a prooftype that uses DNS-based Authentication
>    of Named Entities (DANE) for associating a domain name with an XML
>    stream in the Extensible Messaging and Presence Protocol (XMPP).  It
>    also defines a method that uses DNS Security (DNSSEC) for securely
>    delegating a source domain to a derived domain in XMPP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-miller-xmpp-dnssec-prooftype-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDvcaQACgkQNL8k5A2w/vxOswCfSD5OrV7Fgj0gkgrFaBfroWks
> HWAAn0hwNNsP0pPiX+lRwoz0sEEHj53X
> =8YV7
> -----END PGP SIGNATURE-----
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/
tQgxP

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 13 Feb 2013 15:50:37 +0100 (CET)

> I've been chatting with Florian about this the two standards for proving ownership in the case of a delegating domain hosting.
> 
> Some background: Florian hosts many XMPP domains and at buddycloud, we're putting plans in place to host XMPP domains. In both cases, the more we have to ask customers to configure on their end, the less chance there is of a successful deployment.
> 
> Right now this is:

No security at all, right? (other than server dialback)

> I have huge concerns about expecting customers to provide proofs at the web layer. Especially something that runs on their "main" website. Some reasons off the top of my head:

Well, then the POSH proof type (or an equivalent integrated into 
draft-daboo-aggregated-service-discovery) can not be used by another xmpp 
server to discover the certificate for that domain.

> c) their website is created or hosted by their marketing agency / some other less technical. A simple website push could overwrite their .well-known record could kill their messaging service.

hosting providers will have to protect .well-known.

> d) it's complicated.
> 
> DNSSEC is being rolled out. Sure some registrar and TLDs will take longer to deploy, but in the long term, I think this is the right way to have customers (especially non-technical customers who would rather delegate hosting) delegate their hosting.

Then deploy DNSSEC. Smart servers will (might) try that first and gradually fall back to POSH (or equivalent) and may resort to dial-back as a "who cares about security as long as it works" method.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 13 Feb 2013 15:45:30 +0000

Hello Simon,

Thanks for your feedback.  I have more comments inline.

> a) customer edits their DNS and point it at our servers. Nothing else.

Today this provides no actual verification in and of itself.  To be trusted, that hosting provider must present a certificate with the source domain's identifier.  This is becoming more and more difficult to do if the hosting provider and the source domain are not the same thing.

Alternatively, the hosting provider could acquire a certificate+private key from the source domain, and carry the liabilities that having that private key carries.

> a) Messaging team is different to web team - slow or no deployment.

Reality is that deployment requires coordination. I do appreciate the difficulties that arise with coordination, but trust sometimes requires coordination.

> b) no website hosted on their domain - do we now host web stuff too?

For POSH, it would mean having enough of an HTTPS server to either present the certs, or have a HTTPS-level redirect.

> .well-known record could kill their messaging service.

They would need to protect .well-known, but this would be true of just about anything that gets placed on a web server.

> d) it's complicated.

Please elaborate on what exactly is complicated about POSH.

> hosting) delegate their hosting.

Personally, I don't think DNSSEC will be useable for several years.  Not only does each domain need to have signed records, but just about all of the recursive resolvers would need to leave any response (answer + additional + authority) from their upstream unmolested.  It would also require the clients to do the validation; trusting the "AD flag" from your recursive validating resolver is about as trustworthy as today's dialback.

While parts of these are happening, the implications are still not well understood, which further hurts deployment. POSH is seen by some as a path that we could start to deploy today with a very reasonable chance of success.

If POSH doesn't work for you, then I guess you don't deploy it.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Feb 2013 09:40:28 -0700

> If POSH doesn't work for you, then I guess you don't deploy it.

Exactly. The idea behind DNA is that we have a "framework" for proving
the validity of a server-to-server connection, with (initially) three
different prooftypes:

1. PKI (RFC 6120 / RFC 6125)

2. DNSSEC (draft-miller-xmpp-dnssec-prooftype)

3. POSH (draft-miller-xmpp-posh-prooftype)

Simon / Florian, we'd appreciate your feedback on the whole system
here. Is one of those prooftypes deployable? Maybe two in some
circumstances or for some customers? Matt and I added POSH to the mix
because of difficulties with PKI and DNSSEC in many scenarios. Our
hope is that, for hosting providers and customers who care about
having secure s2s connections, at least one of the prooftypes would
work. If that's not the case, then we might need to think about
defining additional prooftypes (possibilities include some kind of
ticket system a la OAuth, TLS with PGP as in RFC 6091, and other
things that might or might not be easy to implement to deploy either).
But we'll want to make sure that in any given deployment scenario at
least one of the prooftypes is a reasonable approach.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Jensen <[email-masked]>
Date: Wed, 13 Feb 2013 22:05:02 +0000

> No security at all, right? (other than server dialback)

Well, how often don't you trust your DNS ... It's pretty reliable.

> Well, then the POSH proof type (or an equivalent integrated into draft-daboo-aggregated-service-discovery) can not be used by another xmpp server to discover the certificate for that domain.

Correct.

> hosting providers will have to protect .well-known.

So, in our case, we don't always host the Web service. Same for Google. Heck, we host quite a few domains who don't use HTTP at all.

---

From: Florian Jensen <[email-masked]>
Date: Wed, 13 Feb 2013 22:09:56 +0000

Hi,

for 'us webhosts' I believe that DNSSEC is the way forward for secure federation.

It's simple and straight forward for us and customers.

If you want secure federation, get DNSSEC enabled on your domain. Done.

My 2 cents.

Florian

On 13 Feb 2013, at 16:40, Peter Saint-Andre <[email-masked]> wrote:

> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRG8H7AAoJEOoGpJErxa2pxpwQAKR4jXvopHo8pS8vvWk3dVB3
> 2/cJIoEhQjc+OvopFg17ck8T8azErE29cctWfnztocPV+63K4tsSepDI14MnkzoC
> HqwHOx7MnZpud6VBpvlHErpyT3S6Ch9AFjrBgodP7fG34JrOUe5ikWhz1XtJII86
> 2en0sfIe5QnYhJqF3+F8GoaimcUXK21EG3x5sM3gKswXLt5uBhFW5zk9mE1PlUOK
> lRJWZHSCCceUv/Ry//e07hIblog+vsY59q9rRHjlsLpeGbzoZ+OBLbtixQh1fLuf
> XzZYNDSyKs/p2p9w9iOqw7RuefqDa8jKe2l2wSwqY77WWWe2V+lbeCHI6XlH4j2/
> 0p7hyFsRWshne6h1b4xx5d905MaWViuIDCS+WHo35umQDoD6pAsRZHpK2QgCCzyp
> 6EU1XBPyToNQMpU/JeeYWM3OP2TQ4UzpFaySDk+OD+4uV9e5evCaY6YiA5kUkF06
> cr6vAZYNn17qn3k29MEA2GLW0LJwVtG3vrdKU2wBYZcXTMJIgDmiZa+vlLUYUV03
> yVrLLcl/DHvW4ekLgzFaSh5nGbxlAAFmq32RmcwmH89ltTFTnJBVaTnf3C8sHr5j
> M/RNpfY3vFPAqeFui/9tOf3TGqN/AXJ7hHRLd8COm2IQKu6P/AdIK5Bnnn8CeJsH
> dkPaZvsgtt7HWpNGeRZ7
> =sdvF