Re: comments on draft-miller-xmpp-e2e-06

On 3/7/14, 6:23 AM, "Matt Miller" <[email protected]> wrote:

><snip>
>> - It would be nice to have a summary of new state information the
>> sender and recipient are required to manage (like SMKs) and
>> significant new operations (like authorization of key requests
>> where a given recipient may use a number of different public keys)
>
>That is a very good suggestion.  Do you think you could provide some
>text to get it started?

Here¹s some text as a starting point:

Existing XMPP clients will need to maintain additional state information
and incorporate new user interfaces to support end-to-end encryption and
authentication.  Changes for sending clients include:

- Generate session master keys (SMKs)
- Store SMKs for use during active sessions
- Store SMKs to provide to peers and to support reading of saved messages
(may require use of storage key)
- Accept requests for SMKs
- Release SMKs to authorized requestors (where SMK may be requested from
multiple resources each using different means to authenticate)
- Generate content encryption keys (CEK)
- Use SMK and CEK values to encrypt XMPP stanzas
- Generate signing key (optional)
- Use signing key to sign XMPP stanzas

Changes for receiving clients include:

- Send request for SMK to peers
- Store SMK for use during active session
- Use SMK to decrypt CEK used to decrypt XMPP stanzas
- Store session master keys retrieved from peers to support reading of
saved messages (may require use of storage key)
- Provide indication to users when encryption is in use
- Retrieve keys required to verify signatures on signed XMPP stanzas
- Verify signatures and display indication of success/failure to user
- Store keys required to verify signature to support reading of saved
messages (may require use of storage key)


>><snip>
>>- Include some guidance on SMK lifetime.
>
>There is *some* guidance in section 11.2, but I admit it is rather
>vague.  Could you provide more specific suggestions?

I did not generate any text for this yet because the use of SMKs still
seems unsettled to me.  Some issues:

- including a CEK encrypted for each known end point key plus under an SMK
potentially exceeds size threshold used by some servers
- having each end-point request SMKs from the sender generates additional
traffic
- a sender that communicates with a large number of peers must maintain a
large SMK database for an undetermined period of time
- the sender must be available for a recipient to decrypt messages sent
under an SMK that has not previously been retrieved (this is possibly not
acceptable for all cases where XMPP may be used)
- SMK usage complicates storage of encrypted messages (recipients could
re-encrypt the CEK under a storage key or maintain a database of encrypted
SMKs)