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

[Peter Saint-Andre - &yet <[e-mail]>]

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/