Subject: Re: [xmpp] Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-xmpp-3920bis-19

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Nov 2010 09:42:54 -0700

[Again cc'ing [email-masked], and trimming all but the new issues plus
DISCUSS #1]

On 11/30/10 8:43 AM, Alexey Melnikov wrote:

> 1)
> 4.5.3.  Idle Peer
> 
>    Even if the underlying TCP connection is alive and the stream is not
>    broken, the peer might have sent no stanzas for a certain period of
>    time.  In this case, the peer SHOULD close the stream using the
>    handshake described under Section 4.4.
> 
> SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?
> 
>    If the idle peer does not
>    close the stream, the other party MAY either close the stream using
>    the handshake described under Section 4.4 or return a stream error
>    (e.g., <resource-constraint/> if the entity has reached a limit on
>    the number of open TCP connections or <policy-violation/> if the
>    connection has exceeded a local timeout policy).  However, consistent
>    with the order of layers (specified under Section 13.3), the other
>    party is advised to verify that the underlying TCP connection is
>    alive and the stream is unbroken (as described above) before
>    concluding that the peer is idle.  Furthermore, it is preferable to
>    be liberal in accepting idle peers, since experience has shown that
>    doing so improves the reliability of communication over XMPP networks
>    and that it is typically more efficient to maintain a stream between
>    two servers than to aggressively timeout such a stream.
> 
> This is arguing for MAY above.

Subsequent discussion on the XMPP WG list has me convinced that the
first SHOULD is indeed truly optional, so in my working copy I have
changed it to MAY.

> ----NEW----
> 
> 6)
> 13.8.2.  For Confidentiality Only
> 
>    For confidentiality only, servers SHOULD support TLS with the
>    TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
> 
> Why only a SHOULD?

Because during the secdir review, Yaron Sheffer wondered why we support
confidentiality-only at all. It's not encouraged for client-to-server
connections and really will be used for server-to-server connections
only in the under-documented case of TLS + Server Dialback. Thus a
SHOULD seemed appropriate.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ----NEW----
> 
> 13.7.2.2.1.  Case #1
> 
>    If the client certificate appears to be certified by a certification
>    path terminating in a trust anchor (as described in Section 6.1 of
>    [PKIX]), the server MUST check the certificate for any instances of
>    the XmppAddr as described under Section 13.7.1.4.  There are three
>    possible sub-cases:
> 
>    Sub-Case #1:  The server finds one XmppAddr for which the domainpart
>       of the represented JID matches one of the configured hostnames of
>       the server; the server SHOULD use this represented JID as the
>       validated identity of the client.
> 
>    Sub-Case #2:  The server finds more than one XmppAddr for which the
>       domainpart of the represented JID matches one of the configured
>       hostnames of the server; the server SHOULD use one of these
>       represented JIDs as the validated identity of the client, choosing
>       among them according to local service policies or based on the
>       'to' address of the initial stream header.
> 
> What if the client has multiple accounts on the same server and they use
> the same certificate? (I admit that that might be an obscure case.)
> Should the server be using the 'from' value to differentiate as well?

Yes, that seems reasonable (although I agree that the case is somewhat
obscure). This case might be covered by existing text in Section 13.7.2:

   Once the identity of the stream peer has been validated, the
   validating entity SHOULD also correlate the validated identity with
   the 'from' address (if any; see Section 4.6.1) of the stream header
   it received from the peer.  If the two identities do not match, the
   validating entity SHOULD terminate the connection attempt.

However, the two paragraphs are a bit at odds. I suggest modifying the
paragraph from Section 13.7.2.2.1 as follows:

   Sub-Case #2:  The server finds more than one XmppAddr for which the
      domainpart of the represented JID matches one of the configured
      hostnames of the server; the server SHOULD use one of these
      represented JIDs as the validated identity of the client, choosing
      among them based on the bare JID contained in the 'from' address
      of the initial stream header (if any), based on the domainpart
      contained in the 'to' address of the initial stream header, or in
      accordance with local service policies (such as a lookup in a
      user database based on other information contained in the
      client certificate).

> 13.9.4.  Use of SASL
> 
>    Many deployed XMPP services authenticate client connections by means
>    of passwords.  It is well-known that most human users choose
>    relatively weak passwords.  Although service provisioning is out of
>    scope for this document, XMPP servers that allow password-based
>    authentication SHOULD enforce minimal criteria for password strength
>    to help prevent dictionary attacks.  Because all password-based
>    authentication mechanisms are susceptible to password guessing
>    attacks, XMPP servers MUST implement common rate-limiting
>    mitigations.
> 
> Rate-limiting during SASL authentication?

It's not rate limiting, it's limiting the number of authentication
retries. Corrected in my working copy to:

   Because all password-based
   authentication mechanisms are susceptible to password guessing
   attacks, XMPP servers MUST limit the number of retries allowed during
   SASL authentication, as described under Section 6.4.5.

> 13.9.5.  Use of TLS
> 
>    Implementations of TLS typically support multiple versions of the
>    Transport Layer Security protocol as well as the older Secure Sockets
>    Layer (SSL) protocol.  Because of known security vulnerabilities,
>    XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
>    See Appendix E.2 of [TLS] for further details.
> 
> This should probably point to draft-ietf-tls-ssl2-must-not.

Hey, that draft borrowed the idea from the XMPP WG. :P

But sure. Do you think that needs to be a normative reference?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Nov 2010 18:38:20 +0000

>first SHOULD is indeed truly optional, so in my working copy I have
I like that.

>SHOULD seemed appropriate.
I think the use of SHOULD here is misleading. You meant "SHOULD support 
confidentiality only", but you really didn't mean that if it is 
supported than TLS (with the specified cipher) SHOULD be used. I think 
the latter is a MUST.

>      user database based on other information contained in the
This looks reasonable to me.

>   SASL authentication, as described under Section 6.4.5.
Thanks, that is what I was getting at.

>Hey, that draft borrowed the idea from the XMPP WG. :P
:-)

>But sure. Do you think that needs to be a normative reference?
I don't think so, although it would be nice to get them published together.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Nov 2010 11:57:19 -0700

Trimmed as needed...

>> On 11/30/10 8:43 AM, Alexey Melnikov wrote:

<snip/>

> supported than TLS (with the specified cipher) SHOULD be used. I think

Correct. Changed to MUST in my working copy.

<snip/>

> I don't think so, although it would be nice to get them published together.

Yes, that would be nice.

In my working copy that paragraph now reads:

   For further details, see Appendix E.2 of [TLS] along with [TLS-SSL2].

Peter

-- 
Peter Saint-Andre
https://stpeter.im/