Subject: [xmpp] 3920bis tweaks

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Aug 2010 08:20:17 -0600

Before the Chairs request an IETF Last Call on 3920bis, I think we need
to make the following slight modifications:

1. Based on Last Call feedback, draft-saintandre-tls-server-id-check no
longer includes text about the preference order of identifiers in
certificates. Therefore, we need to adjust Section 13.7.1.2.1 of 3920bis.

2. In a hallway conversation in Maastricht, someone mentioned to me that
Section 4.5.1 ("Idle Peer") of 3920bis is slightly ambiguous, because it
might be taken to imply that stanza-level traffic supersedes TCP-level
traffic (such as whitespace keepalives). We can clarify this matter by
changing the order of subsections in Section 4.5 or by adding a few
words to Section 4.5.1.

I'll propose text on these points in the next day or so.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Aug 2010 09:39:00 -0600

> certificates. Therefore, we need to adjust Section 13.7.1.2.1 of 3920bis.

That section currently reads:

###

13.7.1.2.1. Rules

   In a digital certificate to be presented by an XMPP server (i.e., a
   SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include
   one or more JIDs (i.e., domainparts) associated with domains serviced
   at the server.  The rules and guidelines defined in [TLS-CERTS] apply
   to XMPP server certificates.  The following preference order of
   identifiers is RECOMMENDED, where the identifier types are as
   described in [TLS-CERTS] unless otherwise noted.

   1.  SRV-ID (see also [PKIX-SRV])
   2.  DNS-ID
   3.  XmppAddr as specified under Section 13.7.1.4
   4.  CN-ID

   XMPP client and server software implementations MUST be able to
   validate both the SRV-ID and DNS-ID identifier types.  Certification
   authorities that issue XMPP-specific certificates MUST support the
   DNS-ID identifier type and SHOULD support the SRV-ID identifier type.
   Service providers SHOULD request and prefer certificates that include
   an SRV-ID identifier type.  Support for the XmppAddr and CN-ID
   identifier types is encouraged for the sake of backward-
   compatibility.

###

I propose the following modified text:

###

13.7.1.2.1. Rules

   In a digital certificate to be presented by an XMPP server (i.e., a
   SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include
   one or more JIDs (i.e., domainparts) associated with domains serviced
   at the server.  The rules and guidelines defined in [TLS-CERTS] apply
   to XMPP server certificates.  XMPP client and server software
   implementations MUST be able to validate both the SRV-ID and DNS-ID
   identifier types described in [TLS-CERTS].  Certification
   authorities that issue XMPP-specific certificates MUST support the
   DNS-ID identifier type and SHOULD support the SRV-ID identifier type.
   Service providers SHOULD request and prefer certificates that include
   the SRV-ID identifier type.  Support for the XmppAddr identifier
   type (specified under Section 13.7.1.4) and the CN-ID identifier
   type (described in [TLS-CERTS]) is encouraged for the sake of
   backward-compatibility.

###

> changing the order of subsections in Section 4.5 or by adding a few

Here I think it would be good to follow the order of layers by first
describing the handling of dead TCP connections, then the handling of
broken streams, then the handling of idle peers. So in Section 4.5 we
would have:

   When an entity that is a party to a stream has not received any XMPP
   traffic from its stream peer for some period of time, the peer might
   appear to be silent.  There are several reasons why this might
   happen:

   1.  The underlying TCP connection is dead.

   2.  The XML stream is broken despite the fact that the underlying TCP
       connection is alive.

   3.  The peer is idle and simply has not sent any XMPP traffic over
       its XML stream to the entity.

Then we would reverse the order of Sections 4.5.1, 4.5.2, and 4.5.3, as
follows:

   4.5.1. Dead Connection

   4.5.2. Broken Stream

   4.5.3. Idle Peer

I suggest the following text tweaks to the second and third of those
sections:

###

4.5.2. Broken Stream

   Even if the underlying TCP connection is alive, the peer might never
   respond to XMPP traffic that the entity sends, whether normal
   stanzas or specialized stream-checking traffic such as the
   application-level pings defined in [XEP-0199] or the more
   comprehensive stream management protocol defined in [XEP-0198].  In
   this case, it is appropriate for the entity to terminate a broken
   stream using the <connection-timeout/> stream error described under
   Section 4.8.3.4.

###

and:

###

4.5.3. Idle Peer

   Even if the underlying TCP connection is alive and the stream is not
   broken, the peer might not have sent any stanzas for a certain
   period of time.  In this case, the peer SHOULD close the stream
   using the handshake described under Section 4.4.  However, if the
   idle peer does not close the stream, the other party to the stream
   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
   (Section 13.3), the other party is advised to check the underlying
   TCP connection and the stream itself 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.

###

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Aug 2010 10:08:28 -0600

>    than to aggressively timeout such a stream.

That text has some less-than-perfect grammar and might still be
considered a bit ambiguous. I think this is a bit better:

###

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

###