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

Carl Wallace <carl@redhoundsoftware.com> Fri, 14 March 2014 13:19 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95E81A0145 for <xmpp@ietfa.amsl.com>; Fri, 14 Mar 2014 06:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG4cNdiZMs0r for <xmpp@ietfa.amsl.com>; Fri, 14 Mar 2014 06:19:39 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1122D1A013D for <xmpp@ietf.org>; Fri, 14 Mar 2014 06:19:38 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id j5so7341291qga.4 for <xmpp@ietf.org>; Fri, 14 Mar 2014 06:19:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.224.11.10 with SMTP id r10mr3469225qar.8.1394803172076; Fri, 14 Mar 2014 06:19:32 -0700 (PDT)
Received: from [192.168.2.4] (pool-173-79-106-67.washdc.fios.verizon.net. [173.79.106.67]) by mx.google.com with ESMTPSA id s6sm16038344qad.22.2014.03.14.06.19.29 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:19:31 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Fri, 14 Mar 2014 09:19:25 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Matt Miller <mamille2@cisco.com>, <xmpp@ietf.org>
Message-ID: <CF486882.139FE%carl@redhoundsoftware.com>
Thread-Topic: [xmpp] comments on draft-miller-xmpp-e2e-06
References: <CF3DFA91.12C98%carl@redhoundsoftware.com> <5319AC20.4090906@cisco.com>
In-Reply-To: <5319AC20.4090906@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HPh1C1BjBVNY2UCzzqwMvASzSbQ
Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 13:19:41 -0000

On 3/7/14, 6:23 AM, "Matt Miller" <mamille2@cisco.com> 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)