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

Carl Wallace <> Fri, 14 March 2014 13:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C95E81A0145 for <>; Fri, 14 Mar 2014 06:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yG4cNdiZMs0r for <>; Fri, 14 Mar 2014 06:19:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1122D1A013D for <>; Fri, 14 Mar 2014 06:19:38 -0700 (PDT)
Received: by with SMTP id j5so7341291qga.4 for <>; Fri, 14 Mar 2014 06:19:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=j8RatKb/DQmuVbAAT0B/88/xuipP97lDaz0JqQZJa7U=; b=ZA6pEvfvhYgmxuK0RG4OrCrlhvcIgbPN3lpLPp0le028BTu5vRMYwS/W6hSxNQc5ju zuWiEZ58jTEQ405NWQIjVjkYrHwTepVp/n015SKPB5PHDDiP6jXOQ4/6cDMDEJw6t2T2 xxuPIWykkceY85TDj9OEHVNcY0zFoKoLxebMBTQN8fAwf6tgmIXTsOhQLkY93P3jxvK1 l1QZPnq5lgyJkWpKpwdXgRL4oXwT82MNa/j5rL1kQx8dR0xyv04mDxqnKzi0orIjF5nH cWY1A5ixQmFKaTRyZkwZ9En+gqGzkxLHQKOmQUJtPHzIxSdWeBdUtpAhFtRx1ZNFSKMN 5nHQ==
X-Gm-Message-State: ALoCoQmHkhVzrhe38RrCoDhjMWDqtTaFuCk1Dp17bv17P6R47DfWXZ7gaD2zXEGw1Vz1a2HNUP4N
X-Received: by with SMTP id r10mr3469225qar.8.1394803172076; Fri, 14 Mar 2014 06:19:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s6sm16038344qad.22.2014. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:19:31 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Fri, 14 Mar 2014 09:19:25 -0400
From: Carl Wallace <>
To: Matt Miller <>, <>
Message-ID: <>
Thread-Topic: [xmpp] comments on draft-miller-xmpp-e2e-06
References: <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Mar 2014 13:19:41 -0000

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

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

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