Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xmpp-05
"Roni Even" <ron.even.tlv@gmail.com> Sat, 04 April 2015 06:31 UTC
Return-Path: <ron.even.tlv@gmail.com>
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 B079B1A90B9; Fri, 3 Apr 2015 23:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 8mUMa6CtXCKf; Fri, 3 Apr 2015 23:31:08 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 2A52B1A90B6; Fri, 3 Apr 2015 23:31:08 -0700 (PDT)
Received: by wgbdm7 with SMTP id dm7so125186659wgb.1; Fri, 03 Apr 2015 23:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=3vIWRi2vhzhZPbb2TIU8iYyg5kNn1QgbHVebCLOLsSE=; b=YboN127OiPC0n0Es3Sj9d5JM8IvPKPHFIZgsHNrS+GjpS2A0Cnvus6+WtR0WiMWyX/ RDbio2knryJTbmAvmYNhmnBom7ScP2EU3Kd0hEQuaS6zB7wxVjcD87vJzsm2f/kS2pcE 4Sv37DJC7Bn4cJWvvKxCXNZZcsnwA6ICjh6x8oZQImwmCEC/nsfNU3pytkeqLM4BPV99 ppvXZxS47MNRde7HhILSszKAjd/yKBlLjS111BKIRYJowK7iLo2d+3WxkewOdeaEIVY2 zR58rE2sRaxkYz9MuHZUjH9Ysy6rxaPjzza+hmZH+Gj1h5Xp4wtQpqOTs1zSQ/x7jrTV gpfA==
X-Received: by 10.194.20.67 with SMTP id l3mr11199346wje.94.1428129066940; Fri, 03 Apr 2015 23:31:06 -0700 (PDT)
Received: from RoniE (bzq-79-177-166-235.red.bezeqint.net. [79.177.166.235]) by mx.google.com with ESMTPSA id ha10sm14339982wjc.37.2015.04.03.23.31.04 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Apr 2015 23:31:06 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Peter Saint-Andre - &yet' <peter@andyet.net>, draft-ietf-uta-xmpp.all@tools.ietf.org
References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com> <551EC0E0.3010003@andyet.net> <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> <551F0148.30000@andyet.net> <551F0715.2030504@andyet.net>
In-Reply-To: <551F0715.2030504@andyet.net>
Date: Sat, 04 Apr 2015 09:30:58 +0300
Message-ID: <025b01d06ea0$ec061a30$c4124e90$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJMf+mV10+6viYGXJ9VPRCzfMuAZQKfVnJAAyJyA8gBzZaSIgH3TDSdm/gMhMA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/iM_W4XUquuvvEgs0l9wMJWa2Wao>
X-Mailman-Approved-At: Sat, 11 Apr 2015 09:27:32 -0700
Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' <xmpp@ietf.org>
Subject: Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xmpp-05
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: Sat, 04 Apr 2015 06:31:10 -0000
Hi Peter, This text looks good Thanks Roni > -----Original Message----- > From: Peter Saint-Andre - &yet [mailto:peter@andyet.net] > Sent: 04 April, 2015 12:33 AM > To: Roni Even; draft-ietf-uta-xmpp.all@tools.ietf.org > Cc: gen-art@ietf.org; ietf@ietf.org; 'XMPP Working Group'; uta@ietf.org > Subject: Re: Gen-ART LC review of draft-ietf-uta-xmpp-05 > > On 4/3/15 3:08 PM, Peter Saint-Andre - &yet wrote: > > On 4/3/15 2:47 PM, Roni Even wrote: > >> Hi Peter, > >> The new text address my comments, I just have a proposal on section > >> 3.5 see > >> inline > > > > <snip/> > > > >>>> Section 3.4 may look like authentication is a MUST but section 3.5 > >>>> talks about unauthenticated connections > >>> > >>> Well, there are client-to-server connections and server-to-server > >> connections in > >>> XMPP. The former need to be authenticated and the latter do not > >>> (although > >> we > >>> are working on ways to make authentication easier and more pervasive > >>> for server-to-server connections). I thought we had captured that in > >>> the text, > >> but > >>> perhaps not. > >> [Roni Even] Maybe start section 3.5 saying that it is only about > >> server to server connection, currently the end of the section says " > >> this at least enables encryption of server-to-server connections." > >> But I did not understand it as saying that this section is only about > >> server to server connection. > > > > Well, it *mostly* applies to server-to-server connections (there are > > cases with multi-tenanted environments where something like DANE also > > helps for client-to-server connections). The whole topic is messy on > > the client side because of bad user habits about click-through > > security, trust on first use, overriding defaults, etc. Here is a proposed > change. > > > > OLD > > Given the pervasiveness of passive eavesdropping, even an > > unauthenticated connection might be better than an unencrypted > > connection (this is similar to the "better than nothing security" > > approach for IPsec [RFC5386]). Unauthenticated connections include > > connections negotiated using anonymous Diffie-Hellman algorithms or > > using self-signed certificates, among other scenarios. In > > particular, because of current deployment challenges for > > authenticated connections between XMPP servers (see > > [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details), it can be > > reasonable for XMPP server implementations to accept unauthenticated > > connections when Server Dialback keys [XEP-0220] are used; although > > such keys on their own provide only weak identity verification (made > > stronger through the use of DNSSEC [RFC4033]), this at least enables > > encryption of server-to-server connections. > > > > NEW > > Although as just described authentication of the receiving entity is > > either mandatory (for client-to-server connections) or strongly > > preferred (for server-to-server connections), given the pervasiveness > > of eavesdropping [RFC7258] even an unauthenticated connection might > > be better than an unencrypted connection (this is similar to the > > "better than nothing security" approach for IPsec [RFC5386]). > > Unauthenticated connections include connections negotiated using > > anonymous Diffie-Hellman algorithms or using self-signed > > certificates, among other scenarios. > > > > At present there are deployment challenges for authenticated > > connections between XMPP servers, especially in multi-tenanted > > environments (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for > > details). In some of these scenarios, it can be reasonable for XMPP > > server implementations to accept unauthenticated but encrypted > > connections when Server Dialback keys [XEP-0220] are used; such keys > > on their own provide only weak identity verification (made stronger > > through the use of DNSSEC [RFC4033]), but this at least enables > > encryption of server-to-server connections. The Domain Name > > Associations (DNA) prooftypes described in the previous section are > > intended to mitigate the residual need for unauthenticated > > connections in these scenarios. > > I don't think that text is quite right. I suggest that we merge the sections on > Authenticated Connections and Unauthenticated Connections, as follows: > > 3.4. Authenticated Connections > > Both the core XMPP specification [RFC6120] and the "CertID" > specification [RFC6125] provide recommendations and requirements for > certificate validation in the context of authenticated connections. > This document does not supersede those specifications (e.g., it does > not modify the recommendations in [RFC6120] regarding the Subject > Alternative Names or other certificate details that need to be > supported for authentication of XMPP connections using PKIX > certificates). > > Wherever possible, it is best to prefer authenticated connections > (along with SASL [RFC4422]), as already stated in the core XMPP > specification [RFC6120]. In particular, clients MUST authenticate > servers and servers MUST authenticate clients. > > This document does not mandate that servers need to authenticate peer > servers, although such authentication is strongly preferred and > servers SHOULD authenticate each other. Unfortunately, in multi- > tenanted environments it can be extremely difficult to obtain or > deploy PKIX certificates with the proper Subject Alternative Names > (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details). To > overcome that difficulty, the Domain Name Associations (DNA) > specification [I-D.ietf-xmpp-dna] describes a framework for XMPP > server authentication methods, which include not only PKIX but also > DNS-Based Authentication of Named Entities (DANE) as defined in > [I-D.ietf-dane-srv] and PKIX over Secure HTTP (POSH) as defined in > [I-D.ietf-xmpp-posh]. These methods can provide a basis for server > identity verification when appropriate PKIX certificates cannot be > obtained or deployed. > > Given the pervasiveness of eavesdropping [RFC7258] even an > unauthenticated connection might be better than an unencrypted > connection in these scenarios (this is similar to the "better than > nothing security" approach for IPsec [RFC5386]). Unauthenticated > connections include connections negotiated using anonymous Diffie- > Hellman algorithms or using self-signed certificates, among others. > In particular for XMPP server-to-server interactions, it can be > reasonable for XMPP server implementations to accept unauthenticated > but encrypted connections when Server Dialback keys [XEP-0220] are > used; such keys on their own provide only weak identity verification > (made stronger through the use of DNSSEC [RFC4033]), but this at > least enables encryption of server-to-server connections. The Domain > Name Associations (DNA) prooftypes described above are intended to > mitigate the residual need for unauthenticated connections in these > scenarios. > > Peter > > -- > Peter Saint-Andre > https://andyet.com/
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Roni Even
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Roni Even