Re: Gen-ART LC review of draft-ietf-uta-xmpp-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Peter

--
Peter Saint-Andre
https://andyet.com/





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]