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

Matt Miller <> Fri, 07 March 2014 11:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1902F1A0294 for <>; Fri, 7 Mar 2014 03:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Sc0xRfbQHuo for <>; Fri, 7 Mar 2014 03:23:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7F4A31A01E0 for <>; Fri, 7 Mar 2014 03:23:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8109; q=dns/txt; s=iport; t=1394191396; x=1395400996; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=TTPMapyVkMZDspLmgNfKvSihIS3vgOpr+/niaooHoCo=; b=jRAaWR4okN2LZoLi9k2ylwjR0+vd8Mgc2sTsVfP8FZiD9Ud0jly5UDFo YjN9WkjgdYtwuuPDLqcwYzgt1xTkCQmuuam2LbMieXPDQbSXLErNx+Tuv 46uSOxLOfsAtR2pBRMD6vG/jb3R0TkSdSBMnyctUplfOeCZbI5622EMGN Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="305667790"
Received: from ([]) by with ESMTP; 07 Mar 2014 11:23:16 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s27BNFwS020944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 11:23:15 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 7 Mar 2014 05:23:14 -0600
Message-ID: <>
Date: Fri, 7 Mar 2014 11:23:12 +0000
From: Matt Miller <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Carl Wallace <>, <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
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, 07 Mar 2014 11:23:23 -0000

Hash: SHA512

Thank you very much for the feedback!

I'll incorporate your suggestions as soon as I can.

On 3/6/14, 3:12 PM, Carl Wallace wrote:
> 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.

We did discuss reviving the e2e-reqs draft in the WG session on
Tuesday, but it would be important to include this.

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

There is little (read: nothing) that can be said on what existing
"legacy" end-points ought to do.  I tried to say something on what
existing clients already do, to the best of my knowledge.  Many (most)
drop anything they don't understand, so getting errors could very well
be impossible unless the applications were specifically updated to
"anti-support" this specification.  It's also possible I'm missing the
point here, too (-:

The intention is not for the sending end-point to only send to other
supporting end-points.  Indeed, I want this to be compatible with
[CARBONS] and [MUC] where the possible.  To that end, most clients try
to do something if there is a body, and this document could suggest
that sending end-points include an appropriate generic "this message
is protected" body.

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

The encrypted CEK is included in each message with -06.

Including an encrypted SMK is a possibility, although I start to worry
about the size of the overall stanza.  If it's absolutely known that
the message will be delivered to a single end-point it shouldn't get
too large, but I am assuming that servers will start multiplexing chat
messages (a la [CARBONS]) which means the benefits of including the
encrypted SMK are unrealized if only there's only a single instance of
the encrypted SMK; including multiple SMKs can be very problematic
(e.g., many server deployments reject very large stanzas).

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

I'm not sure what you're trying to say here (it could be due to me
responding on the last day of an IETF meeting).  Can you provide an
example of what your concern here is?

> - Discuss how multiple recipients are handled

That is a very good point.  There is some text there, but it is fairly
weak.  I was considering a form of ASCII sequence diagram of the
general flow -- would that better help to explain things?

> - s/optionallly/optionally

Fixed in working copy.

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

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

That is not a bad idea.  I'll look into it.

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

Is there any additional concern here beyond the point a few above?

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

These are good points, and it ought to be included.  The JWS structure
does allow for inclusion of the jwk (or jku, or x5c, or x5t, or x5u)
which would be the key used to sign the content.  I'll add more
clarity on this point.

> - s/Playload/payload

Fixed in working copy.

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

That is a good point.

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

I have been hesitant on dictating what to display to users.  I don't
want to tie the hands of implementations, and it's rather difficult to
independently verify that a given implementation complies without some
sort of officiating body (which we definitely don't want).

> - May want to distinguish between successful authentication vs
> successful verification


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

I thought I had said that in here, but I'll clarify it further.

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

You have this reversed: the SMK is used to encrypt the CEK, and the
recipient's public key is used to encrypt the SMK.  It is completely
possible that I was not consistent here.

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

Encrypted CEKs are in the payload in -06.

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

You mean encrypted SMKs here.

One idea that had been discussed outside the meeting was to try and
use [PEP] as a way to do this, but we didn't spend a lot of time
thinking about the mechanics and implications here.

> - Need to address authorization for SMK release.

I have pretty much hand-waved over this part.  One idea that came to
light this week was to provide fingerprints for the recipients' public
keys, somehow.  Suggestions for improvements are welcome.

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

- -- 
- - m&m

Matt Miller < >
Cisco Systems, Inc.

[CARBONS] XEP-0280: Message Carbons < >
[MUC] XEP-0045: Multi-User Chat < >
[PEP] XEP-0163: Personal Eventing Protocol < >

Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -