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

["Richard L. Barnes" <[e-mail]>]

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

Yes.




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

Ok.