[xmpp] Questions on POSH (WAS: Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt]

["Matt Miller (mamille2)" <[e-mail]>]

Hello Simon,

Thanks for your feedback.  I have more comments inline.

On Feb 13, 2013, at 7:02 AM, Simon Tennant <[e-mail]>
 wrote:

> 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.

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.

> 
> 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.

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.

> 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.

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.

> 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.
> 

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 < [e-mail] >
Cisco Systems, Inc.

> 
> On 11 January 2013 02:57, Peter Saint-Andre <[e-mail]> 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: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>> 
>> 
>> 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
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xmpp
>> 
> 
> 
> 
> -- 
> Simon Tennant | buddycloud.com | [phone] | office hours: goo.gl/
> tQgxP
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp