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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 03 Apr 2015 10:33:36 -0600

Hi Roni, thanks for the review.

On 4/3/15 3:59 AM, Roni Even wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-uta-xmpp-05
>
> Reviewer: Roni Even
>
> Review Date:2015–4-3
>
> IETF LC End Date: 2015–4-13
>
> IESG Telechat date:
>
> Summary: This draft is not ready for publication as an Standard Track  RFC.
>
> Major issues:
>
> I am wondering why this document is a standard track and not
> Informational, reading it I get the impression that it repeats text from
> RFC6120 and does not provide new normative information.

Ah, I see the confusion.

Earlier versions of this document repeated the recommendations from 
draft-ietf-uta-tls-bcp and explicitly applied them to XMPP. At some 
point we refactored the document so that it wasn't repeating the text 
(because that's usually a bad idea - things can get out of sync etc.), 
but in the process we lost those normative statements.

To fix the problem, I suggest that we change the following paragraph and 
move it to be the first paragraph of Section 3:

OLD
       NOTE: Unless explicitly noted otherwise, all of the
       recommendations specified in [I-D.ietf-uta-tls-bcp] apply to XMPP.
       In the main, this document merely provides supplementary
       information; those who implement and deploy XMPP technologies are
       expected to follow the recommendations of [I-D.ietf-uta-tls-bcp].

NEW
       XMPP implementations and deployments MUST follow the
       recommendations provided in [I-D.ietf-uta-tls-bcp] unless
       explicitly noted otherwise herein.  Instead of repeating those
       recommendations here, this document mostly provides supplementary
       regarding implementation and deployment of XMPP technologies.

> Section 3.1 talks about TLS support and say that it SHOULD be tried  but
> since it is a SHOULD I assume that failure may happen and non TLS
> connections may be used ( I am not sure what RFC6120 say about it.

Section 3.1 attempts to say this (but clearly we did not phrase things 
very well): the lack of an indication that a connection endpoint 
supports TLS SHOULD NOT prevent a connecting entity from attempting TLS 
negotiation. In fact, I think we could say MUST NOT (the "SHOULD" comes 
from local policy).

Therefore I suggest the following rewording:

OLD
    The server (i.e., the XMPP receiving entity) to which a client or
    peer server (i.e., the XMPP initiating entity) connects might not
    offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns
    :xmpp-tls'/>.  Although in general this stream feature indicates that
    the server supports XMPP 1.0 and therefore supports TLS, it is
    possible that this stream feature might be stripped out by an
    attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]).  Therefore,
    the initiating entity SHOULD proceed with the stream negotiation even
    if the receiving entity does not advertise support for TLS.
    Similarly, although a receiving entity SHOULD include the <required/>
    child element to indicate that negotiation of TLS is mandatory, an
    initiating entity MUST NOT depend on receiving the <required/> flag
    in determining whether TLS will be enforced for the stream.

NEW
    The server (i.e., the XMPP receiving entity) to which a client or
    peer server (i.e., the XMPP initiating entity) connects might not
    offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns
    :xmpp-tls'/>.  Although in general this stream feature indicates that
    the server supports XMPP 1.0 and therefore supports TLS, it is
    possible that this stream feature might be stripped out by an
    attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]).
    Similarly, the <required/> child element of the <starttls/> stream
    feature is used to indicate that negotiation of TLS is mandatory,
    but could also be stripped out by an attacker. Therefore, the
    initiating entity MUST NOT be deterred from attempting TLS
    negotiation even if the receiving entity does not advertise support
    for TLS.  Instead, the initiating entity SHOULD (based on local
    policy) proceed with the stream negotiation and attempt to negotiate
    TLS.

> 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.

> On section 3.7 I assume that providing e2e information is based on the
> XMPP architecture that may have only one server to server hop.  Are
> there other cases?

In Section 3.7 we weren't trying to say that information can be provided 
about the end-to-end encryption status of all the hops along a 
communications path because that's impossible (at least in a way that 
can be trusted). We might adjust the text to avoid any confusion, as 
follows:

OLD
    o  Determine if a client-to-server or server-to-server connection is
       encrypted and authenticated.
    o  Determine the version of TLS used for a client-to-server or
       server-to-server connection.

NEW
    o  Determine if a given incoming or outgoing XML stream is
       encrypted and authenticated using TLS.
    o  Determine the version of TLS used for a given stream.

Peter

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 3 Apr 2015 23:47:37 +0300

Hi Peter,
The new text address my comments, I just have a proposal on section 3.5 see
inline

Roni

> -----Original Message-----
> From: Peter Saint-Andre - &yet [mailto:[email-masked]]
> Sent: 03 April, 2015 7:34 PM
> To: Roni Even; [email-masked]
> Cc: [email-masked]; [email-masked]; XMPP Working Group; [email-masked]
> Subject: Re: Gen-ART LC review of draft-ietf-uta-xmpp-05
> 
> > Review Date:2015-4-3
> > IETF LC End Date: 2015-4-13
> >
> > IESG Telechat date:
> >
> Earlier versions of this document repeated the recommendations from draft-
> ietf-uta-tls-bcp and explicitly applied them to XMPP. At some point we
> refactored the document so that it wasn't repeating the text (because
that's
> usually a bad idea - things can get out of sync etc.), but in the process
we lost
> those normative statements.
> 
move
> it to be the first paragraph of Section 3:
> 
> OLD
[Roni Even] This is clearer now
> 
> > Section 3.1 talks about TLS support and say that it SHOULD be tried
> > but since it is a SHOULD I assume that failure may happen and non TLS
very well):
> the lack of an indication that a connection endpoint supports TLS SHOULD
NOT
> prevent a connecting entity from attempting TLS negotiation. In fact, I
think we
> could say MUST NOT (the "SHOULD" comes from local policy).
> 
[Roni Even] OK
> 
> > Section 3.4 may look like authentication is a MUST but section 3.5
> > talks about  unauthenticated connections
> 
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.
> In Section 3.7 we weren't trying to say that information can be provided
about
> the end-to-end encryption status of all the hops along a communications
path
> because that's impossible (at least in a way that can be trusted). We
might
> adjust the text to avoid any confusion, as
> follows:
> 
> OLD
[Roni Even] OK

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 03 Apr 2015 15:08:24 -0600

> The new text address my comments, I just have a proposal on section 3.5 see

<snip/>

> understand it as saying that this section is only about server to server

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/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 03 Apr 2015 15:33:09 -0600

>     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/

---

From: "Roni Even" <[email-masked]>
Date: Sat, 4 Apr 2015 09:30:58 +0300

Hi Peter,
This text looks good
Thanks
Roni

> Sent: 04 April, 2015 12:33 AM
> Cc: [email-masked]; [email-masked]; 'XMPP Working Group'; [email-masked]
> >>> 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.
> >
> > 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.
sections on
> Authenticated Connections and Unauthenticated Connections, as follows:
>