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

["Roni Even" <[e-mail]>]

Hi Peter,
This text looks good
Thanks
Roni

> -----Original Message-----
> From: Peter Saint-Andre - &yet [mailto:[e-mail]]
> Sent: 04 April, 2015 12:33 AM
> To: Roni Even; [e-mail]
> Cc: [e-mail]; [e-mail]; 'XMPP Working Group'; [e-mail]
> 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/