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

Florian Jensen <admin@flosoft.biz> Wed, 13 February 2013 22:05 UTC

Return-Path: <admin@flosoft.biz>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16221F8889 for <xmpp@ietfa.amsl.com>; Wed, 13 Feb 2013 14:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4vzzgbMWjAc for <xmpp@ietfa.amsl.com>; Wed, 13 Feb 2013 14:05:35 -0800 (PST)
Received: from core1.flosoft-servers.net (flosoft.biz [178.33.33.198]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0E21F8886 for <xmpp@ietf.org>; Wed, 13 Feb 2013 14:05:34 -0800 (PST)
X-No-Relay: not in my network
Received: from homer.ldn.flosoft-servers.net (cpc18-slam5-2-0-cust142.2-4.cable.virginmedia.com [86.26.230.143]) by core1.flosoft-servers.net (Postfix) with ESMTPSA id 2DE3D416DB6 for <xmpp@ietf.org>; Wed, 13 Feb 2013 23:06:55 +0100 (CET)
From: Florian Jensen <admin@flosoft.biz>
Content-Type: multipart/signed; boundary="Apple-Mail=_26B8F1E7-E7F9-4186-B5BE-CC5FF341681B"; protocol="application/pkcs7-signature"; micalg="sha1"
Message-Id: <4A967520-23F9-4518-8246-CBC1700AC392@flosoft.biz>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Wed, 13 Feb 2013 22:05:02 +0000
References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> <CACEE+iPix6zGpFDC0KAOyR+33_2wdzPtyiFTDn7di7-T6vZKqw@mail.gmail.com> <alpine.DEB.2.00.1302131510250.2647@lo.psyced.org>
To: XMPP Working Group <xmpp@ietf.org>
In-Reply-To: <alpine.DEB.2.00.1302131510250.2647@lo.psyced.org>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [xmpp] I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 22:05:35 -0000

On 13 Feb 2013, at 14:50, Philipp Hancke <fippo@goodadvice.pages.de> 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.
> 
> No security at all, right? (other than server dialback)

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

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

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

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.

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