Last Call Review of draft-ivov-xmpp-cusax-06
review-ivov-xmpp-cusax-06-genart-lc-carpenter-2013-07-10-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ivov-xmpp-cusax-06-genart-lc-carpenter-2013-07-10

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ivov-xmpp-cusax-06.txt
Reviewer: Brian Carpenter
Review Date: 2013-06-24
IETF LC End Date: 2013-07-16
IESG Telechat date:

Summary:  Almost ready
--------

Comment:
--------

I have some issues, but I don't know whether to classify any of them as
major.

Issues:
-------

In Introduction:

"  As a result, a number of adopters have found themselves needing
   features that are not offered by any single-protocol solution, but
   that separately exist in SIP and XMPP implementations.  The idea of
   seamlessly using both protocols together would hence often appeal to
   service providers. "

A few paragraphs later, you discuss the case of an end user who would like
to use SIP and XMPP together with *different* service providers. I would suggest
ending this sentence with "appeal to service providers and users."

"  Finally, this document makes a further simplifying assumption by
   discussing only the use of a single client, not use of and
   coordination among multiple endpoints controlled by the same user
   (e.g., user agents running simultaneously on a laptop computer,
   tablet, and mobile phone)."

Hmm. Isn't that the normal case today, and your simplifying assumption
the exception? It's certainly extremely annoying to have different
contacts lists on different devices, for example. This seems like a
big gap in the model, with no hints on how it might be filled. (As big
as the gap between POP3 and IMAP, in some ways.)

In Client Bootstrap:

"  While it should be possible for CUSAX users to manually configure
   their separate SIP and XMPP accounts, service providers offering
   CUSAX services to users of dual-stack SIP/XMPP clients ought to
   provide means of online provisioning,..."

1. I would anyway expect my CUSAX client to come with a configuration
wizard, including a path to the online provisioning if available.

2. Is there any reason why SIP service providers and XMPP service
providers shouldn't individually provide on-line provisioning? You're
describing something close to a captive-customer scenario, rather than
encouraging an open approach to provisioning. The CUSAX client would
in any case have to deal with any inconsistencies in provisioning.

In Server-Side Setup:

"  In order for CUSAX to function properly, XMPP service administrators
   should make sure that at least one of the vCard [RFC6350] "tel"
   fields for each contact is properly populated with a SIP URI or a
   phone number when an XMPP protocol for vCard storage is used (e.g.,..."

How can they do that, given that users are normally responsible for
maintaining their contacts lists?

In Summary of Suggested Practices:

"  1.   By default, prefer SIP for audio and video, and XMPP for
        messaging and presence."

At the beginning of the Operation section, this seems to be stated as
a rule, not as a default (" Audio/video features however, are disabled
in the XMPP stack..."). Which is it?

In Security Considerations:

"  ... a CUSAX client might
   successfully negotiate Transport Layer Security (TLS) [RFC5246] when
   connecting to the XMPP aspect of the service but not when connecting
   to the SIP aspect.  Such mismatches could introduce the possibility
   of downgrade attacks."

I'd say *would* introduce the possibility. It would seem possible for a
bad actor to pick up authentication data from the insecure service and
exploit it to attack the secured service. Therefore,

"  User agent developers and service providers
   ought to ensure that such mismatches are avoided as much as possible."

seems a bit weak. Shouldn't the client also be *required* to alert the user
that the session as a whole is not secured?