Subject: Re: [xmpp] Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-xmpp-address-07

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Nov 2010 14:29:05 -0700

Hi Alexey, this email message provides proposed text to address your
DISCUSSes and COMMENTs.

On 11/22/10 8:31 AM, Peter Saint-Andre wrote:
> On 11/19/10 5:20 AM, Alexey Melnikov wrote:
>> Alexey Melnikov has entered the following ballot position for 
>> draft-ietf-xmpp-address-07.
>>
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>>
>> Please refer to
>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>>
>>
>> ----------------------------------------------------------------------
>>
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>  I just can't possibly resist not having a DISCUSS on this document
>> ;-). 
> 
> You would. :P
> 
>> Below are my review comments:
>>
>> 1). RFC 3920:
>>
>> domain          = fqdn / address-literal fqdn            =
>> (sub-domain 1*("." sub-domain)) sub-domain      = (internationalized
>> domain label) address-literal = IPv4address / IPv6address
>>
>>
>> draft-ietf-xmpp-address:
>>
>> domainpart    = IP-literal / IPv4address / ifqdn ; the "IPv4address"
>> and "IP-literal" rules are ; defined in RFC 3986, and the
>> first-match-wins ; (a.k.a. "greedy") algorithm described in RFC ;
>> 3986 applies to the matching process
>>
>>
>> RFC 3986:
>>
>> IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
>>
>> IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
>>
>> (DISCUSS DISCUSS) This means that the draft is proposing usage of "["
>> and "]" around IPv6 addresses, which is a change from RFC 3920. I
>> think the change is sensible, but is it covered by Appendix C?
> 
> Yes, that's missing from the summary of changes. The ABNF fixes
> attempted to align the formal definition with both existing standards
> (e.g., RFC 3986) and existing usage. I don't think that the IPv6
> correction was specifically called out in the WG, though.

In Section 2.1, I've added the following additional note:

      domainpart    = IP-literal / IPv4address / ifqdn
                      ; the "IPv4address" and "IP-literal" rules are
                      ; defined in RFC 3986, and the first-match-wins
                      ; (a.k.a. "greedy") algorithm described in RFC
                      ; 3986 applies to the matching process
                      ;
                      ; note well that re-use of the IP-literal rule
                      ; from RFC 3986 implies that IPv6 addresses are
                      ; enclosed in square brackets (i.e., beginning
                      ; with '[' and ending with ']'), which was not
                      ; the case in RFC 3920

In Appendix C, I've modified that bullet point as follows:

   o  Corrected the ABNF syntax to ensure consistency with [URI] and
      [IRI]; one consequence is that IPv6 addresses are enclosed in
      square brackets (i.e., beginning with '[' and ending with ']').

>> 2). In Section 2.1:
>>
>> An XMPP URI or IRI [XMPP-URI] is in essence a JID prepended with
>> 'xmpp:', but the native addressing format used in XMPP is that of a
>> mere JID without a URI scheme.
>>
>> I think this text is misleading for URIs: it is effectively
>> suggesting that percent-decoding/encoding is not needed when
>> converting a JID to URI, which is not correct. URIs are always in
>> US-ASCII, while JIDs are not. Similar assumptions about mailto: URIs
>> caused some interoperability problems.
> 
> It should say:
> 
>    An XMPP IRI ...
> 
> Not:
> 
>    An XMPP URI or IRI...

In Section 2.1, I've removed "URI or" from that sentence:

   An XMPP IRI [XMPP-URI] is in essence a JID prepended with 'xmpp:';
   however, the native addressing format used in XMPP is that of a mere
   JID without a URI scheme.

>> 3). [DNS] seems to be Normative (for the definition of a Fully
>> Qualified Domain Name).
> 
> Yes.

I've moved that reference from Section 7.2 to Section 7.1.

>> 4). DISCUSS DISCUSS: Should domainpart be migrated to IDNA2008 now?
>> Apps Area is pretty much requiring use of IDNA2008 in all documents.
> 
> This spec documents the legacy usage as a placeholder while the XMPP
> community contributes to the PRECIS WG in its work on a replacement for
> stringprep. I think the XMPP WG agreed that it would move away from
> stringprep for all parts of a JID at the same time -- not temporarily
> replace IDNA2003 with IDNA2008 for the domainpart but keep using
> stringprep for the localpart and resourcepart pending the output of the
> PRECIS WG, and then switch the localpart and resourcepart over to a
> non-stringprep approach once the PRECIS WG is done.

See other thread.

>> 5). I still need to double check the following, but from a cursory
>> look this seems to be a minor problem:
>>
>> Can application of Nodeprep/resourceprep to a non empty string result
>> in an empty string, which would violate the requirement on
>> nodepart/resourcepart being non empty?
>>
>> This will affect several sections, including Section 6.
> 
> I think this is possible, and XMPP implementations need to (and, AFAIK,
> do) enforce the non-zero-length restriction. IMHO this works as designed
> and is not a problem, but perhaps needs to be called out in the text.

In Sections 2.2, 2.3, and 2.4 respectively, I've modified the relevant
paragraphs as follows:

   A domainpart MUST NOT be zero bytes in length and MUST NOT be more
   than 1023 bytes in length.  This rule is to be enforced after any
   mapping or normalization resulting from application of the Nameprep
   profile of stringprep (e.g., in Nameprep some characters can be
   mapped to nothing, which might result in a string of zero length).

   A localpart MUST NOT be zero bytes in length and MUST NOT be more
   than 1023 bytes in length.  This rule is to be enforced after any
   mapping or normalization resulting from application of the Nodeprep
   profile of stringprep (e.g., in Nodeprep some characters can be
   mapped to nothing, which might result in a string of zero length).

   A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
   than 1023 bytes in length.  This rule is to be enforced after any
   mapping or normalization resulting from application of the
   Resourceprep profile of stringprep (e.g., in Resourceprep some
   characters can be mapped to nothing, which might result in a string
   of zero length).

>> ----------------------------------------------------------------------
>>
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>  1). In 4.3.1 SASL needs an Informative Reference
> 
> Yes.

In Section 7.2, I've added a reference for RFC 4422.

In Section 4.3.1, I've modified the relevant sentence as follows:

   In the context of XMPP technologies, address forging occurs when an
   entity is able to generate an XML stanza whose 'from' address does
   not correspond to the account credentials with which the entity
   authenticated onto the network (or an authorization identity provided
   during negotiation of SASL authentication [SASL] as described in
   [XMPP]).

>> 2).
>>
>> o  A resourcepart can be employed as one part of an entity's address 
>> in XMPP.  One common usage is as the name for an instant messaging 
>> user's connected resource; another is as the nickname of a user in a
>> multi-user chat room; and many other kinds of entities could use 
>> resourceparts as part of their addresses.  The security of such 
>> services could be compromised based on different interpretations of
>> the internationalized resourcepart; for example, a user could attempt
>> to bind multiple resources with the same name,
>>
>> Can you expand on what is the problem with binding multiple resources
>> to the same name?
> 
> Authorization decisions could be based on a full JID, not a bare JID. In
> general we don't recommend that when building authorization into various
> XMPP extensions, but it's not disallowed.

In Section 4.3.2, I've modified the relevant paragraph as follows:

   o  A resourcepart can be employed as one part of an entity's address
      in XMPP.  One common usage is as the name for an instant messaging
      user's connected resource; another is as the nickname of a user in
      a multi-user chat room; and many other kinds of entities could use
      resourceparts as part of their addresses.  The security of such
      services could be compromised based on different interpretations
      of the internationalized resourcepart; for example, two or more
      confusable resources could be bound to the same bare JID
      (resulting in inconsistent authorization decisions in an XMPP
      application), or a user could send a message to someone other than
      the intended recipient in a multi-user chat room.

>> 3). In Section 6:
>>
>> Feature:  address-domain-length Description:  Ensure that the
>> domainpart of an XMPP address is at least one byte in length and at
>> most 1023 bytes in length.
>>
>> Domain names have lower length boundary due to DNS restrictions. 
>> Should this be at least mentioned? (Also applies elsewhere)
> 
> Yes, it should. Nothing in this spec shall be taken to override the DNS
> specifications. I thought we'd added a sentence about length limits from
> DNS, but apparently not.

In Section 2.2, I've added the last sentence to the following paragraph:

   A domainpart MUST NOT be zero bytes in length and MUST NOT be more
   than 1023 bytes in length.  This rule is to be enforced after any
   mapping or normalization resulting from application of the Nameprep
   profile of stringprep (e.g., in Nameprep some characters can be
   mapped to nothing, which might result in a string of zero length).
   Naturally, the length limits of [DNS] apply, and nothing in this
   document is to be interpreted as overriding those more fundamental
   limits.

In Section 6, I've changed the relevant feature to:

   Feature:  address-domain-length
   Description:  Ensure that the domainpart of an XMPP address is at
      least one byte in length and at most 1023 bytes in length, and
      conforms to the underlying length limits of the DNS.
   Section:  Section 2.2
   Roles:  Both MUST.

Let me know if these adjustments address your feedback.

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Nov 2010 11:47:33 +0000

>Hi Alexey, this email message provides proposed text to address your
Hi Peter,

>      square brackets (i.e., beginning with '[' and ending with ']').
Works for me.

>   JID without a URI scheme.
Ok.

>I've moved that reference from Section 7.2 to Section 7.1.
Thanks.

>>non-stringprep approach once the PRECIS WG is done.
Yes, this certainly need more discussion, as opinions on the subject differ.

>   characters can be mapped to nothing, which might result in a string
Works for me.

>   during negotiation of SASL authentication [SASL] as described in
Ok.

>      the intended recipient in a multi-user chat room.
This is better, thanks.

>      conforms to the underlying length limits of the DNS.
Nit: "underlying domain length limit of the DNS". But the current text 
is Ok as well.

>Let me know if these adjustments address your feedback.
Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address