Re: [Stox] Spencer Dawkins' No Objection on draft-ietf-stox-im-12: (with COMMENT)

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

Hi Spencer, thanks for the review. Comments inline.

On 3/4/15 10:11 PM, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-stox-im-12: No Objection
>
> 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.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-stox-im/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm glad to see these specifications moving forward. Thanks for that.
>
> I have a couple of you-need-smarter-ADs questions. As prologue, please
> remember I have a decent understanding of SIP, an indecent understanding
> of SIMPLE, and mostly, I just stare uncomprehendingly when I see raw
> XMPP.
>
> It did not jump out at me when reading this specification, whether there
> is any assurance to a sender on one side of the gateway that a message
> was delivered successfully to a receiver on the other side of the
> gateway.

Assurance is a slippery thing. :-)

In XMPP we do have a way to communicate delivery receipts end-to-end 
<http://xmpp.org/extensions/xep-0184.html> but that's an extension to 
the core specs. Given that MSRP has a similar mechanism for session mode 
messaging, we talk about that in draft-ietf-stox-chat instead of 
draft-ietf-stox-im.

> If there's not, that might be worth pointing out a bit earlier
> than a Note: halfway through page 5.
>
> Is there a possible mismatch between what a sender thinks is happening,
> TLS-wise, on one side of the gateway, and what a receiver actually
> receives, TLS-wise, on the other side? I'm not smart enough to ask the
> right question, but if an XMPP sender knows she's sending over TLS, but
> the XMPP-to-SIP gateway maps that into a non-TLS SIP transaction on the
> other side, is the kind of scenario I'm thinking of. If so, perhaps it's
> worth pointing that out someplace (the Security Considerations section
> would be fine).

RFC 7247 says:

    As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630],
    a To header or a Request-URI containing a Session Initiation Protocol
    Secure (SIPS) URI is used to indicate that all hops in a
    communication path need to be protected using TLS.  Because XMPP
    lacks a way to signal that all hops need to be protected, if the To
    header or Request-URI of a SIP message is a SIPS URI then the SIP-to-
    XMPP gateway MUST NOT translate the SIP message into an XMPP stanza
    and MUST NOT route it to the destination XMPP server (there might be
    exceptions to such a policy, such as explicit agreement among two
    operators to enforce per-hop security, but currently they are quite
    rare).

Do you feel that we need to say more here in the IM context?

Peter

-- 
Peter Saint-Andre
https://andyet.com/