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

Matt Miller <> Fri, 06 June 2014 14:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FC161A0114 for <>; Fri, 6 Jun 2014 07:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Igu_v6znOmHz for <>; Fri, 6 Jun 2014 07:20:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD0A71A0092 for <>; Fri, 6 Jun 2014 07:20:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14618; q=dns/txt; s=iport; t=1402064425; x=1403274025; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0T7iKqrIDGJxXwe4BqrDzZzfaNrAseyZdnBqvA3T6qA=; b=i+i+3rp9DNdPUv55hQwYJn97ZAHy7J8JwzEaGC7L6tlmFdGYRtJqwv4g Q1F1zuulhWXUF/CRGmeGEGkLzgldojO5qE1bCiGV6DE9ZtY4zOpd5yFxV brYH61O0YyVhH9AoV3Ka/c/RaI3AfQ0LPukca78VYJ8nIcmso8S2AEpWt E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,989,1392163200"; d="scan'208";a="331132789"
Received: from ([]) by with ESMTP; 06 Jun 2014 14:20:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s56EKNBR002526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 14:20:23 GMT
Received: from MAMILLE2-M-T03K.CISCO.COM ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Jun 2014 09:20:23 -0500
Message-ID: <>
Date: Fri, 6 Jun 2014 08:20:24 -0600
From: Matt Miller <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Simon Tennant <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Cc: "<> Group" <>
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, 06 Jun 2014 14:20:34 -0000

Hash: SHA512

Hello Simon!

On 6/6/14, 5:56 AM, Simon Tennant wrote:
> Hi Matt,
> A few high-level questions:
> * Do I understand it correctly that all keys are session based and 
> there isn't a pgp style key that the user publishes in a
> directory? I guess I'm not clear on how the keys are created or
> exchanged or looked up for contacts.

the keys are session based; the recipients use <keyreq/> sub-protocol
(§ 5) to request the session key from the sender.  The <keyreq/> does
use an asymmetric key that the recipient provides to the sender.  This
draft is leaving most of how that key is verified up to
implementations right now.

> * How would this handle me sending a <message> to an offline
> contact? Or retrieving encrypted messages after being offline for a
> while?

The current one would not handle that approach, and this shortcoming
is discussed in § 9.

> * Could this work for component to component  / user to component 
> messages?

I see no reason for it not to work, as long as the components and users

> * Are keys always session based? Would it be possible to hook into 
> other key directories?

I don't think this prevents other key management schemes from being
used.  As long as those specs properly described the mapping between
'sid' and the extended key management schemes, and how to signal that
another management scheme is in use.

- -- 
- - m&m

Matt Miller < >
Cisco Systems, Inc.

> ᐧ
> On 18 March 2014 21:59, Matt Miller < 
> <>> wrote:
> On 3/7/14, 5:28 AM, Carl Wallace wrote:
>> On 3/7/14, 6:23 AM, "Matt Miller" <
> <>> wrote:
>> 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.
>>> It¹s also worth noting the sender may have multiple end points 
>>> with the same properties.  If the same SMK were used in
>>> replies, it creates kind of a odd scenario where both parties
>>> could be providing the SMK for the asking.
> Good point.
>>>>> 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.
>>> I¹ve not yet looked, but I had wondered if it would be
>>> possible to define the signature format so a non-supporting
>>> client could still display the text (similar to cleartext email
>>> vs opaque). This probably brings a can of canonicalization
>>> worms though.
> There is an XSF XEP that covers this using a different technology,
> and calls it opportunistic signatures.
> My experience has been that opportunistic signatures opens a very 
> large can of worms, which is why I avoided it in my draft.  There
> are additional considerations for <iq/>s, since the expectation is
> for there to be a single child element (except for type='error',
> where there is also an <error/> in the parent's namespace).
> We could decide to remove signatures from this draft almost
> entirely, and leave it as someone else's exercise to deal with in
> the general case.  In this scenario, I envision keeping some form
> of signature is to aid in authenticating PFS key exchanges, but
> then it can be specific to the keyreq then.
>>>>> - 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.
>>> I made this error a couple of times.  What I meant was
>>> encrypted CEK for a key already held by the end point, to avoid
>>> to the need for a round trip to get the SMK, to remove the
>>> online requirement for the sender at recipient reading time and
>>> to simplify future use of stored encrypted messages.  The CEK
>>> could also be encrypted under the SMK to bootstrap unknown end
>>> points.
>> 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).
>>> Do you know what the threshold is?
> The threshold is different for different deployments /-:
> There are some without any limit, which means the system crashes if
> it runs out of memory trying to deal with an extremely large
> stanza. Another I'm aware of has a limit of 40KB, and will drop the
> connection on anything bigger.
> I don't know how common any particular limit is, though.  And
> worse, there's no real way to detect prior to trying.
>>>>> - 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?
>>> Assume a sender has used two SMKs while communicating with a 
>>> given recipient: sender+recipient+SMK1 and
>>> sender+recipient+SMK2. The current text requires the SID to be
>>> unique "for a given (sender, recipient, SMK) tuple².  That
>>> allows for the same SID to be used for either SMK1 or SMK2. I
>>> am suggesting the SID should be unique for each recipient, from
>>> a sender¹s perspective.
> I see your point now.
>>>>> - 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?
>>> That would help.
>>>>> - 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?
>>> Sure.  Will try to send something next week.
>>>>> - 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?
>>> No, just looking for another place to not use of a key already 
>>> know to the receiver.
>>>>> 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).
>>> I thought these UI notes were more reminders to developers to 
>>> make sure user¹s could determine checks had been performed.
> I'm sure we can come up with something that's not exactly
> normative language.
>>>>> - May want to distinguish between successful
>>>>> authentication vs successful verification
>> Noted.
>>>>> 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.
>>> I thought when the SMK is communicated to the end point, it is 
>>> also encrypted under a content encryption key (referred to as
>>> a CMK in the text), that is then encrypted using the end
>>> point¹s public key.  If that is correct there are four keys at
>>> work: the CEK for the stanza (CEK1), the SMK to encrypt the
>>> CEK, the CEK to encrypt the SMK (CEK2) and the recipient¹s
>>> public key to encrypt CEK2.
> You are absolutely correct; sorry for my own confuzzlement!
>>>>> 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.
>>> I tried to clarify in a reply comment above.  This applies to
>>> the next few comments too.  Read ³encrypted CEKs² are ³CEKs
>>> encrypted using a key already possessed by the recipient².  I
>>> think I was consistent in misusing the term ³encrypted CEKs² in
>>> my comments in this way, and introduced the CEK term in my
>>> comments where it does not appear in the draft:-)
>>>>> 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?
>>> As above, will try to send some text next week.
> _______________________________________________ xmpp mailing list 
> <> 
> -- Simon Tennant | <> | +49 17
> 8545 0880 | office hours: <>
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -