Hi Peter, This text looks good Thanks Roni > -----Original Message----- > From: Peter Saint-Andre - &yet [mailto:peter@xxxxxxxxxx] > Sent: 04 April, 2015 12:33 AM > To: Roni Even; draft-ietf-uta-xmpp.all@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx; 'XMPP Working Group'; uta@xxxxxxxx > 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/