Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP
Peter Saint-Andre - &yet <peter@andyet.net> Tue, 19 May 2015 15:42 UTC
Return-Path: <peter@andyet.net>
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 394791A9077 for <xmpp@ietfa.amsl.com>; Tue, 19 May 2015 08:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Q-BJA_no1ahj for <xmpp@ietfa.amsl.com>; Tue, 19 May 2015 08:42:22 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CED1A90FD for <xmpp@ietf.org>; Tue, 19 May 2015 08:41:36 -0700 (PDT)
Received: by pacwv17 with SMTP id wv17so29585374pac.2 for <xmpp@ietf.org>; Tue, 19 May 2015 08:41:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sl0z3MLOksXZwCJN3E2gKXVU/LHJPS82DEP9Gp6iRt0=; b=Wm7k+ioLT7fssvYk3uiMKOMtILiJveDT9TDTWf3qKuxs3VA4JOH4TuF9+r7JtO50rA j12XHunZvA0c50Vr6cmamvPCEv6nd9drEq46EuN/MeuNQLF3U98iNf1D8rj/V67fdtYL ERI4k1bzzSmT5Ap5V2m4nAb9pQBPujMJsNsG5oa88vAzxXy4URORA1REo6uQeQeaUjnj 4PTgQakJMPthydaZhzfG86Sn36yEN6/g69N4YXHLnq+aQGf9nozZ76jEOsXQA+rU2MaH kwTzovznDkV27El7E9/NsRNyhR0FFocaasFE6ZQz2VVWw0QqlSDaaETTB+AMr/CPvULH SVlA==
X-Gm-Message-State: ALoCoQmo1zvyWkUsBnq86HOSUd/LhroqA49acgT7SFIOOTzEndXQ/dFi5l3SBiHEsW0pZDc2cHJr
X-Received: by 10.70.6.161 with SMTP id c1mr54854606pda.76.1432050096372; Tue, 19 May 2015 08:41:36 -0700 (PDT)
Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id ql9sm13430161pbc.65.2015.05.19.08.41.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 08:41:35 -0700 (PDT)
Message-ID: <555B59AD.2030700@andyet.net>
Date: Tue, 19 May 2015 08:41:33 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: XMPP Working Group <xmpp@ietf.org>
References: <555A61CA.2020108@andyet.net> <555A6319.9010703@andyet.net> <555A6684.4000100@andyet.net>
In-Reply-To: <555A6684.4000100@andyet.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/K3XqhVTtmCpUUsjLIWfmcfsuMi4>
Subject: Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP
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: Tue, 19 May 2015 15:42:24 -0000
On 5/18/15 3:24 PM, Peter Saint-Andre - &yet wrote: > On 5/18/15 3:09 PM, Peter Saint-Andre - &yet wrote: >> This thread started on the DANE WG list but I think it belongs here. >> >> >> -------- Forwarded Message -------- >> Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP >> Date: Mon, 18 May 2015 15:03:54 -0700 >> From: Peter Saint-Andre - &yet <peter@andyet.net> >> To: dane@ietf.org >> >> On 5/17/15 9:55 AM, Kim Alvefur wrote: >>> Hello list! >> >> Hi Zash! >> >>> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >>> to='xmpp23.hosting.example.net' in the stream header, as that is the >>> "functional equivalent" of SNI in XMPP. However, that conflicts with >>> the current semantics of 'to' being the service domain name to the >>> server host name. That will break many, if not all, deployed servers. >>> The server should know what certificate to use for the indicated domain >>> name. >>> >>> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >> >> Hmm. >> >> First, all draft-ietf-dane-srv says is that you don't need to use SNI in >> XMPP because we already have a way for the TLS client to specify which >> domain name it expects of the TLS server, i.e., the 'to' address of the >> initial stream header. >> >> Second, draft-ietf-xmpp-dna is the document that specifies the behavior >> of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the >> DANE WG list. I'll forward this message to that list and continue the >> conversation there. :-) > > So, draft-ietf-xmpp-dna (§5.1) says: > > The DANE prooftype makes use of the DNS-Based Authentication of Named > Entities [RFC6698], specifically the use of DANE with DNS SRV records > [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: > > o If there is no SRV resource record, pursue the fallback methods > described in [RFC6120]. > > o Use the 'to' address of the initial stream header to determine the > domain name of the TLS client's reference identifier (since use of > the Server Name Indication extension (TLS SNI) [RFC6066] is purely > discretionary in XMPP, as mentioned in [RFC6120]). > > As I understand it, Kim is saying that if a client were to (i) discover > via SRV methods that the service domain "example.com" is located at the > target server "hosting.example.net" and (ii) discover via DANE methods > that the expected identity of the certificate for the connection > endpoint is not the service domain but the target server host name, then > (iii) it would break things on the XMPP network for the client to > specify a 'to' address of the target server host name instead of the > service domain because (iv) the XMPP server software figures out which > certificate to present based on the service domain, not the target > server host name. > > I'm not sure about that. It seems to me that if an application service > provider is doing the whole DANE thing, then it will always just present > a certificate for "hosting.example.net" instead of for "example.com" or > any particular service domain hosted there, so why does it even need to > differentiate? > > Now, there might be some other reason to want the 'to' address to be the > service domain (e.g., maybe some cluster or machine is dedicated for > hosting that service domain, or the application service provider wants > to terminate spurious connections as quickly as possible and not use > TLS/SASL resources and round trips for accounts that it doesn't host), > but I'm not yet convinced that choosing the right certificate is the > reason. > > However, I freely admit that I might be missing something, so > enlightenment would be appreciated. :) See further discussion on the DANE list: http://www.ietf.org/mail-archive/web/dane/current/msg07686.html I think draft-ietf-xmpp-dna is fine (it just says "use the 'to' address, not SNI") whereas draft-ietf-dane-srv is the document that needs to be adjusted slightly. Peter -- Peter Saint-Andre https://andyet.com/
- [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional e… Peter Saint-Andre - &yet
- Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI function… Peter Saint-Andre - &yet
- Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI function… Dave Cridland
- Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI function… Peter Saint-Andre - &yet
- Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI function… Peter Saint-Andre - &yet