Re: [xmpp] New(ish) draft: Secure Messaging in XMPP

[Philipp Hancke <[e-mail]>]

Am 23.10.2015 um 14:18 schrieb Adam Roach:
> XMPP folks:
>
> Martin and I put together a proposal for an approach that allows for
> end-to-end encrypted XMPP conversations, including in the presence of
> MUC. Although not a completely implementable spec, this should give a
> good idea about the direction we have in mind:
>
> https://tools.ietf.org/html/draft-thomson-xmpp-secure-00
>
> Anyone interested in this work should give it a read and provide
> feedback.

quite a number of comments and questions...


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.1
   Clients that wish to participate in encrypted messaging publish
   keying material to their presence

we've stopped putting stuff into presence quite a while ago...
See PEP question below. (I assume you don't require compat with ancient 
services like google talk that could never be bothered to implement 
post-2004 features like PEP)


    Each client generates new keying material that is bound to the full
    JID that they use (that is, each client has its own keying material;
    there is no key associated with a user's bare JID).

This is problematic with server-chosen resource parts which change with 
each login. 'static' resources like 'desktop', 'work' or 'iphone' are a 
thing of the past. PEP is likely the answer here.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.2

    Prior to sending a message, a client first retrieves and validates
    the presence of the intended recipient.

Can you explain what you mean with 'first retrieves and validates the 
presence of the intended recipient'?

I suspect the presence model you have in mind is not what XMPP commonly 
does... which is 'broadcast' so no retrieval.


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3
    A user founds a MUC in the usual fashion (see [XEP-0045], section
    10.1).  Two changes are made:

broken link. I would also suggest replacing 'founds' with 'creates' for 
consistency of terminology. But that's just me.


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3.1

    The inviting client generates a signed invitation and sends this to
    the bare JID of the offline user

using what key? The bare JID has no key. If not using MAM this message 
might be delivered to the next client that signs on which might not be a 
client that can decrypt the message.


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4
   <x xmlns="...identity#assertion">

Can you please use other element names? <x/> is very non-descriptive 
which is the reason that new xmpp extensions don't use this style anymore.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.1
    The server uses the client's authentication
    credentials, which are usually bound to a connection, to determine if
    the client owns the identifier.

the identifier being [e-mail]/resource?


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.2
   generates an error, or a message containing the identity.

s/message/result (this refers to an iq-result)


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5

    The routing and message handling information from the cleartext
    (element basename plus to, from, and type attributes)

For <iq/> this should include the id attribute?


    That is, <iq> stanzas produce encrypted <iq> stanzas; <message>

we usually write this as <iq/> and <message/> (also elsewhere)

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.1

    This removes the language indicator from the unencrypted stanza.

Note that the server might re-add the stream's xml:lang when forwarding. 
Not a problem I think, I would just omit the xml:lang in the example. 
It's rarely used anyway.

   To do: check with someone who might know.

should be ignored. Note that the lack of <body/> might affect storage, 
see http://xmpp.org/extensions/xep-0313.html section 5. Also resource 
locking, carbons etc. Multi-client is a hard problem.


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.2.3
    Since there is an expectation of reliability and in-order message
   delivery, clients should highlight where message are missing.

This reliability is only partially achieved when crossing s2s. I need to 
ponder more on this.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.3

    A signature on messages is necessary to prevent impersonation of
    other MUC participants.

wait, why is this now talking about MUC again?

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.5
   Encrypting status is highly desirable.

You'll end up encrypting 'user has been unavailable for 15 minutes' -- 
in languages some of the users friends don't even understand. In 
practice few people use the status.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.6
   Thus, clients are required to suppress chat state notifications when
    a peer is offline.

I think that's already in XEP-0085. Since you don't have presence for 
the peer you don't know their chat state support and should not send 
chat states.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-6.1
Please, don't put stuff into <presence/>. Use PEP. You also want to use 
XEP-0335.


https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-7
I think using 'roster' here is confusing since that is used in 6121 and 
XEP-0045 for slightly different purposes (neither of which makes any 
assertions about validity).



https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-8

I like the idea. It is better than 'just use sasl anonymous' since the 
server can provide this service only to authenticated clients.
In terms of implementation, I think this better described as an 
xmpp-to-xmpp transport.

There is something here which puzzles me:
   Clients are able to include the new pseudonym in any interaction that
   they initiate

Are you assuming that client that requested this would send stanzas with 
from='[e-mail]/someresource'?

Servers will typically override any client-set 'from' which seems to 
have impact on the crypto scheme you're proposing.