[xmpp] Fwd: Re: [dane] DANE XMPP s2s implementation
Peter Saint-Andre <stpeter@stpeter.im> Mon, 10 March 2014 18:15 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D11A04E7 for <xmpp@ietfa.amsl.com>; Mon, 10 Mar 2014 11:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EhSG2qzbK45 for <xmpp@ietfa.amsl.com>; Mon, 10 Mar 2014 11:15:15 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3F1A0691 for <xmpp@ietf.org>; Mon, 10 Mar 2014 11:15:14 -0700 (PDT)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BD12404DE; Mon, 10 Mar 2014 12:15:08 -0600 (MDT)
Message-ID: <531E012B.6060406@stpeter.im>
Date: Mon, 10 Mar 2014 12:15:07 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: XMPP Working Group <xmpp@ietf.org>
References: <20140310161350.GW21390@mournblade.imrryr.org>
In-Reply-To: <20140310161350.GW21390@mournblade.imrryr.org>
X-Forwarded-Message-Id: <20140310161350.GW21390@mournblade.imrryr.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Gr5wgkcdqXz4wnqkfGFaYYM0ft0
Subject: [xmpp] Fwd: Re: [dane] DANE XMPP s2s implementation
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 10 Mar 2014 18:15:24 -0000
FYI from the DANE list. Discussion here seems appropriate. -------- Original Message -------- Subject: Re: [dane] DANE XMPP s2s implementation Date: Mon, 10 Mar 2014 16:13:50 +0000 From: Viktor Dukhovni <viktor1dane@dukhovni.org> Reply-To: dane@ietf.org To: dane@ietf.org On Mon, Mar 10, 2014 at 03:50:17PM +0100, Kim Alvefur wrote: > It's currently only doing DANE-EE and PKIX-EE. I would recommend that, as with the SMTP draft, the XMPP community choose a subset of the DANE usages to support. Either 0/1 or 2/3, but not both. By choosing both you get the weakest security, and the maximal deployment friction (everyone needs to deploy and trust the same set of CAs). So it makes more sense to implement just one of DANE-EE or PKIX-EE, with a plan to later add one of DANE-TA or PKIX-TA respectively. > The TA variants are > trickier, especially DANE-TA, so I have left them out for now. Indeed, especially for DANE-TA, it makes sense to wait until the underlying TLS toolkits: OpenSSL, NSS, GnuTLS, ... support DANE trust chain verification and name checks (integrated with trust validation because DANE-EE obviates name checks, while DANE-TA requires them). Though IIRC the XMPP draft currently just defers all the DANE language to the SRV draft, it may at some point make sense to be more explicit about XMPP-specific choices, unless the SRV draft is modified to define a set of profiles, one of which exactly matches the requirements of XMPP. > It also includes an attempt at doing something for authenticating the > client certificate on incoming connections, by looking for a TLSA record > at the same name as for SRV, eg _xmpp-server._tcp.example.com. Comments > about this would be appreciated. I encourage you to discuss this with the XMPP draft authors, I asked this very question informally and was told that client certificate verification was somehow accomplished via callbacks. If it is reasonable to require the outbound XMPP clients for a domain to possess the same private keys and certificates as the inbound servers, then your approach may reasonable. Though you likely end up taking the union of the TLSA records for all servers, rather than just the specific server you connect to when validating a connection to a server. I would suggest a less ad-hoc strategy for authenticating clients, perhaps a lookup key for TLSA records at: _xmpp-client.example.com IN TLSA ... if client certificates are to be used with XMPP to authenticate the client domain. (Neither _port nor _proto make much sense for clients, the client is not a fixed transport end-point). -- Viktor. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
- [xmpp] Fwd: [dane] DANE XMPP s2s implementation Kim Alvefur
- [xmpp] Fwd: Re: [dane] DANE XMPP s2s implementati… Peter Saint-Andre