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

Carl Wallace <carl@redhoundsoftware.com> Thu, 06 March 2014 15:12 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 562961A0092 for <xmpp@ietfa.amsl.com>; Thu, 6 Mar 2014 07:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7oDgMLGYMOpG for <xmpp@ietfa.amsl.com>; Thu, 6 Mar 2014 07:12:47 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 750AA1A0079 for <xmpp@ietf.org>; Thu, 6 Mar 2014 07:12:47 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id x3so3010509qcv.39 for <xmpp@ietf.org>; Thu, 06 Mar 2014 07:12:43 -0800 (PST)
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:mime-version:content-type:content-transfer-encoding; bh=gsbj3ICEzm0r0Pn8X7TaVVqSNZnWqv3dTBPq9/YbF1c=; b=dctbA7joRza4FhYMdWMgaN45BzpNvZh8WeNyvTZk8DkSoUo8khkBdj1Uhv5f6CBOP4 rCDr4xQNpnbDpM+Z5+2UYKBBj9hdPkctlWp93EPY4Bo7WO0Jf1y9pCjCn8/tPTljneeg BbaIC/4GXxXXe6W7D3IA3kSH0bIuSqAleGkfz3FAfV+HMmsqTnuOtTx5PsbEfjzskXoT inxRmfca9pYUnygXgZ6wX+eovimQlEujHA+vzkc6TTvNGX7CM/cZRUqGFfmId0th0JTv c6DKGuXhvByMUi0VObuFas9/Wg1e8qZAyVZCvDXdKnZ1ziZzhStD829H8i96PecVvSSo iQzA==
X-Gm-Message-State: ALoCoQm5bRgFXkwPkocSxGjJjVASg4a3DJ67JIDCPXdvCBfpPYtPVs87Qq+AYg9y5Vl3+aNvGYw5
X-Received: by 10.224.22.65 with SMTP id m1mr2663466qab.103.1394118763402; Thu, 06 Mar 2014 07:12:43 -0800 (PST)
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 m11sm7978402qge.13.2014.03.06.07.12.38 for <xmpp@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 06 Mar 2014 07:12:42 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Thu, 06 Mar 2014 10:12:33 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: <xmpp@ietf.org>
Message-ID: <CF3DFA91.12C98%carl@redhoundsoftware.com>
Thread-Topic: comments on draft-miller-xmpp-e2e-06
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/m_zxS8NkQPWoo8u0bLWpagiJyXc
Subject: [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: Thu, 06 Mar 2014 15:12:50 -0000

Section 1
- This may be in the reqs draft, but seems worth stating here that some
end points for a given recipient may share keys, some may use different
keys, some may have no keys and some may not support encryption or
signature verification at all.

Section 3
- What should the sender do if some end points for a recipient indicate
lack of support for encryption?  Are error responses helpful independent
of confirmation that some end points support encryption?  Is the intent
for messages to only be sent to end points that advertise support?

- Why not include an end point's key in its info results and enable return
of the encrypted SMK (or even CEK) with the encrypted payload (to save a
round trip).  Given a single message could trigger a number of requests
for the SMK, the option to include the encrypted CEK in the payload may be
worthwhile.  Including the encrypted CEK would help with storage too.
 

- Why is the SID required to be unique for a {sender, recipient, SMK}
tuple?  This would allow for the same SID to be used to name every SMK
used with a recipient.  Suggest unique for each recipient (i.e., SMK's are
uniquely identified by recipient+SID for a given sender).

- Discuss how multiple recipients are handled

- s/optionallly/optionally

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

- Should include an example of a reply to an encrypted message.
Should/must the same SMK be used in replies?

- Is there any reason pre-placed SMK values cannot be used instead of SMK
values retrieved automatically from the sender?

Section 4
- How is the public key used to verify signatures published to the
recipients?  If not included in the payload, should be available a la the
SMK.  This would be useful, at a minimum, when the signer uses a
certificate from a PKI the recipient trusts.

- s/Playload/payload

- Include some text indicating users MUST be able to determine if a
message was authenticated

- Should data be presented to the user when the timestamp is not
acceptable?  There are guidelines for invalid signatures, but not for
unacceptable timestamps.  Same comment on 3.3.5 too.

- May want to distinguish between successful authentication vs successful
verification

Section 5
- Should describe how the entity requesting a key gets the SID

- Should make it more clear that a new CEK is generated in order to
encrypt the SMK, then the CEK is encrypted under the public key.

Section 9
- The requirement for the sender to be online would seem like sufficient
grounds for including encrypted CEKs in the payload.

Section 11
- Offline storage may be another reason to include encrypted CEKs in a
payload.  Perhaps the solution should be to encrypt for each of a
recipient's known keys plus an SMK that could be used by end points using
a different, not-yet-known-to-the-sender key.

- Need to address authorization for SMK release.

- Include some guidance on SMK lifetime.