Re: [xmpp] draft-ietf-xmpp-6122bis-01 feedback

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/11/12 1:15 PM, Florian Zeitz wrote:
> Hi,
> 
> as I had promised some time ago, here are some comments based on a
> full review of draft-ietf-xmpp-6122bis(-01).

Thanks for the review!

> Section 2.1: I realize it has always been that way, but considering
> some people try to rely on it I was wondering whether the ABNF
> should fully specify the requirements for a JID.

I am not a master of ABNF, but I do know that it can be tricky to
specify all of the restrictions in ABNF, so I would prefer not to make
the attempt. However, as document editor, I will incorporate revised
(and accurate) ABNF into the spec if someone else contributes it.

> It currently doesn't convey some aspects, such as length
> restrictions, or the fact that A-labels are invalid as ifqdn. I'd
> suggest at least adding some text saying that the ABNF only lays
> out the basic structure, while other requirements are defined
> below.

That I can easily do. I propose the following change:

OLD
   All JIDs are based on the foregoing structure.

NEW
   All JIDs are based on the foregoing structure.  However, note that
   the foregoing structure does not capture all of the rules and
   restrictions that apply to JIDs, which are described below.

> The example used in the implementation note is no longer valid,
> when using NFC, i.e. U+FE6B does not canonically decompose to
> U+0040. In fact I have not found any characters that are currently
> canonically decomposable to either '@' or '/'.

I haven't found any, either.

> I still feel the note as such is necessary though to be
> future-proof.

We could note that currently this occurs under NFKC, not NFC.

I propose the following change:

OLD
      Implementation Note: When dividing a JID into its component parts,
      an implementation needs to match the separator characters '@' and
      '/' before applying any transformation algorithms, which might
      decompose certain Unicode code points to the separator characters
      (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL
      AT might decompose to U+0040 COMMERCIAL AT).

NEW
      Implementation Note: When dividing a JID into its component parts,
      an implementation needs to match the separator characters '@' and
      '/' before applying any transformation algorithms, which might
      decompose certain Unicode code points to the separator characters
      (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL
      AT decomposes to U+0040 COMMERCIAL AT, although this is not true
      under Unicode Normalization C, which is used in this
      specification).

> Section 2.2: «The domainpart for every XMPP service MUST be a fully
> qualified domain name» I have not been able to find a definition of
> "fully qualified domain name", particularly not in RFC 1035 as the
> current text suggests.

I have never been able to find such a definition, either (I looked
when Jeff Hodges and I were working on RFC 6125). Would you like to
write an Internet-Draft about it? Warning: there be dragons. The
closest thing to a definition can be found in RFC 1034 (not 1035),
which talks about the concept of an absolute domain name (which is
equated to a fully qualified domain name in RFC 1535, see also RFC
1123 with regard to email). However, note that in the DNS, an absolute
domain name ends with ".", so pedants might argue that
"foo.example.com." is an FQDN whereas "foo.example.com" is not.

> I'm somewhat worried that this could be misinterpreted as "a domain
> name as stored in DNS", which would imply A-labels I think. Maybe
> someone more competent than me could comment on this.

I see no reason for such an interpretation. See for example Section
4.2 of RFC 5890:

###

4.2. U-label Lengths

   Labels associated with the DNS have traditionally been limited to 63
   octets by the general restrictions in RFC 1035 and by the need to
   treat them as a six-bit string length followed by the string in
   actual calls to the DNS.  That format is used in some other
   applications and, in general, that representations of domain names as
   dot-separated labels and as length-string pairs have been treated as
   interchangeable.  Because A-labels (the form actually used in the
   DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
   in general, more compressed that UTF-16 or UTF-32), U-labels that
   obey all of the relevant symmetry (and other) constraints of these
   documents may be quite a bit longer, potentially up to 252 characters
   (Unicode code points).  A fully-qualified domain name containing
   several such labels can obviously also exceed the nominal 255 octet
   limit for such names.  Application authors using U-labels must exert
   due caution to avoid buffer overflow and truncation errors and
   attacks in contexts where shorter strings are expected.

###

To allay any concerns, I propose the following change:

OLD
   The domainpart for every XMPP service MUST be a fully qualified
   domain name (FQDN; see [RFC1035]), IPv4 address, IPv6 address, or
   unqualified hostname (i.e., a text label that is resolvable on a
   local network).

NEW
   The domainpart for every XMPP service MUST be a fully-qualified
   domain name (FQDN), an IPv4 address, an IPv6 address, or an
   unqualified hostname (i.e., a text label that is resolvable on a
   local network).

      Informational Note: The term "fully-qualified domain name" is not
      well defined.  In [RFC1034] it also called an absolute domain
      name, and the two terms are associated in [RFC1535].  The earliest
      use of the term can be found in [RFC1123].  References to those
      older specifications ought not to be construed as limiting the
      characters of a fully-qualified domain name to the ASCII range;
      for example, [RFC5890] mentions that a fully-qualified domain name
      can contain one or more U-labels.

> «In the terms of IDNA2008 [RFC5890], the domainpart of a JID is a 
> "domain name slot".» Maybe we should use the more specific term
> "IDNA-aware domain name slot" from that RFC?

Good point.

> The wording «For the purpose of communication over XMPP» is still
> used in this section. It should be harmonized with the following
> sections (I like the new wording by the way).

Ah, I missed that instance. Will fix.

> Section 2.2 - 2.4: «With regard to directionality, the "Bidi Rule"
> provided in [RFC5893] applies.» The Bidi Rule as such only mentions
> Bidi domain names and doesn't "apply" as such. I'd prefer saying
> that the conditions therein MUST be fulfilled.

Actually, Section 2 of RFC 5893 states that "the following rule
applies to labels in Bidi domain names", so one can apply the rule to
strings other than domain names as long as conceptually one
substitutes the term "label" with the term "string". That's how it is
treated in the PRECIS framework document, but you're right that
slightly more careful wording would be helpful.

I propose the following change:

OLD
   With regard to directionality, the "Bidi Rule" provided in [RFC5893]
   applies.

NEW
   With regard to directionality, applications MUST apply the "Bidi
   Rule" defined in [RFC5893] (i.e., each of the six conditions of the
   Bidi Rule must be satisfied).

> Section 3: The conformance requirements mention the rules SHOULD be
> enforced by clients. This is not reflected in this section as such
> (as far as I can tell). In particular I'd like to have an
> implementation note somewhere, reminding client developers that for
> comparison some normalization can be necessary/helpful. E.g. a
> client might send a message to one JID, but receive a reply from a
> normalized version thereof. Interpreting these as separate entities
> can lead to a bad user experience.

Or security problems!

I propose the following changes:

OLD
   Enforcement of the XMPP address format rules is the responsibility of
   XMPP servers.  Although XMPP clients are encouraged to prepare
   complete JIDs and parts of JIDs in accordance with these rules before
   including them in protocol slots within XMPP streams, XMPP servers
   hold the primary responsibility for enforcing the rules.

NEW
   Enforcement of the XMPP address format rules is the responsibility of
   XMPP servers.  Although XMPP clients SHOULD prepare complete JIDs and
   parts of JIDs in accordance with these rules before including them in
   protocol slots within XMPP streams, XMPP servers MUST enforce the
   rules wherever possible.

OLD
   In general, servers are responsible for enforcing the address format
   rules when receiving protocol elements from clients where the server
   is expected to process or act on such elements; two examples from
   [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot
   used by XMPP servers for routing of outbound stanzas) and the
   <resource/> child of the <bind/> element (which is a resourcepart
   slot used by XMPP servers for binding of a resource to an account for
   routing of stanzas between the server and a particular client).
   However, servers are not responsible for enforcing the rules when the
   protocol elements are intended for communication among other
   entities; two examples are the 'initiator' attribute in the Jingle
   extension [XEP-0166] (which is a JID slot used for client-to-client
   coordination of multimedia sessions) and the 'nick' attribute in the
   Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
   used for administrative purposes in the context of XMPP chatrooms).

NEW
   In general, servers are responsible for enforcing the address format
   rules when receiving protocol elements from clients where the server
   is expected to process or act on such elements; two examples from
   [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot
   used by XMPP servers for routing of outbound stanzas) and the
   <resource/> child of the <bind/> element (which is a resourcepart
   slot used by XMPP servers for binding of a resource to an account for
   routing of stanzas between the server and a particular client).
   However, servers are not responsible for enforcing the rules when the
   protocol elements are intended for communication among other
   entities; two examples are the 'initiator' attribute in the Jingle
   extension [XEP-0166] (which is a JID slot used for client-to-client
   coordination of multimedia sessions) and the 'nick' attribute in the
   Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
   used for administrative purposes in the context of XMPP chatrooms);
   in such cases, clients SHOULD enforce the rules, and client
   implementers need to understand that not enforcing the rules can lead
   to a degraded user experience or security vulnerabilities.

> Section 5.3.1: Not sure if it is worth mentioning here, but proper
> TLS certificate checking would mitigate DNS poisoning too.

I think that's already covered by Section 13.9.2 of RFC 6120.

Thanks again,

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+GMiAACgkQNL8k5A2w/vxh5wCgsGNbVs6qFqWhHBYe77El/Skx
LdoAoMbuj2/naM+93Ly36FTkDOM0vtPX
=s65R
-----END PGP SIGNATURE-----