Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt

"Richard L. Barnes" <> Tue, 26 October 2010 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2BF3A696D; Tue, 26 Oct 2010 14:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.408
X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7pkPVHBjOs7R; Tue, 26 Oct 2010 14:46:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A94D3A680B; Tue, 26 Oct 2010 14:46:06 -0700 (PDT)
Received: from [] (port=51411 by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1PArN4-000LpW-7w; Tue, 26 Oct 2010 17:47:54 -0400
Message-Id: <>
From: "Richard L. Barnes" <>
To: Peter Saint-Andre <>
In-Reply-To: <>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 26 Oct 2010 17:47:52 -0400
References: <> <>
X-Mailer: Apple Mail (2.936)
Cc:,, XMPP <>,
Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Oct 2010 21:46:07 -0000

> Is this revised text clearer?
>   For the purpose of communication over an XMPP network (e.g., in the
>   'to' or 'from' address of an XMPP stanza), an entity's address MUST
>   be represented as a JID, not as a Uniform Resource Identifier [URI]
>   or Internationalized Resource Identifier [IRI].  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.  ([XMPP-URI] is provided only for identification and
>   interaction outside the context of XMPP itself, for example when
>   linking to a JID from a web page.)

Yes, that is better, especially with the revision below.

> However, we might want to add the following sentence at the end of the
> revised paragraph quoted above:
>   See [XMPP-URI] for a description of the process for securely
>   extracting a JID from an XMPP URI or IRI.

After taking a better look at RFC 5122, I agree that that sentence is  
all that's needed.

>> S4.3:
>> It seems like there should be some discussion here about how entities
>> that create JIDs can help mitigate issues of confusability.  For
>> example, the existence of confusable characters in the domainpart is
>> mitigated by proper registry policies (which I presume could be
>> incorporated by reference to some IDNA documents).  Localparts and
>> resourceparts are not constrained  to be domain names, but they are
>> controlled or at least approved by a server, so the server can apply
>> similar policies to these parts.
> That said, I think draft-ietf-xmpp-address-06 (you reviewed -05)
> includes some text that might address your concern, to wit:
> ###
> ...
> ###
> Does that help?

That's exactly what I was looking for!  Presumably the same  
considerations apply to resourceparts, so perhaps just one more  
sentence establishing that equivalence would be in order.

>> S4.4.1 P2:
>> The observation that only part of an identifier can be  
>> authenticated is
>> a good one to make, but there's one subtlety: The remote server is
>> actually authoritative for the localpart and resourcepart of the  
>> JID, so
>> the fact that the remote domain has assigned a particular 'from'  
>> address
>> effectively authenticates those fields when the domain is  
>> authenticated.
>> It might help to note that end-to-end authentication of XMPP stanzas
>> could help mitigate this risk, since it would require the rogue  
>> server
>> to generate false credentials in addition to modifying 'from'  
>> addresses.

Any thoughts on this issue?

>> Minor issues:
>> S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be  
>> an
>> IP address or unqualified host name" to "MUST be an FQDN, IPv4  
>> address
>> literal, IPv6 address literal, or unqualified host name".  If the
>> intention here is that unqualified host names should have the same
>> syntax as FQDNs, then that should be stated.
> I take it you mean something like the following edited text:
> ###
>   The domainpart for every XMPP service MUST be a fully qualified
>   domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or
>   unqualifed hostname (i.e., a text label that is resolvable on
>   a local network).
>      Interoperability Note: Domainparts that are IP addresses might
>      not be accepted by other services for the sake of server-to- 
> server
>      communication, and domainparts that are unqualified
>      hostnames cannot be used on public networks because they are
>      resolvable only on a local network.
> ###
> Is that what you were looking for?


>> S2.2 P3: Not clear why this is a "Note:" paragraph, especially  
>> since it
>> has "MUST" requirements in it.
> I've removed the "Implementation Note:" string at the beginning of  
> that
> paragraph.