Subject: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-01.txt

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jun 2012 07:20:34 -0600

FYI, a proposal for XMPP E2E, using JOSE.  This has been updated to the latest JOSE WG drafts.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

Begin forwarded message:

> From: [email-masked]
> Date: June 22, 2012 07:00:24 MDT
> To: [email-masked]
> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
> 	Author(s)       : Matthew Miller
> 	Filename        : draft-miller-xmpp-e2e-01.txt
> 	Pages           : 22
> 	Date            : 2012-06-21
> 
> Abstract:
>   This document defines a method of end-to-end object encryption for
>   the Extensible Messaging and Presence Protocol (XMPP).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01
> 
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-miller-xmpp-e2e-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jun 2012 09:19:19 -0600

A significant item of note: this draft attempts to use "alg":"none" in order to separate the keys from the content, and rely on an exchange of keys outside of the JOSE containers.

I opted not to use "draft-jones-json-web-encryption-json-serialization" because the duplication of headers, with rather minor variances between them, felt overly cumbersome; lots of decoding and parsing to find the right header/key/int combo.  I also have a key distribution problem that I felt the serialization draft makes worse for me.

If there were a good way to separate "properties of the content encryption" from "properties of key encryption", that might make it more palatable.  It wouldn't completely solve my key distribution problem, but I think it would might help.

- m&m

On Jun 22, 2012, at 07:20, Matt Miller wrote:

> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jun 2012 12:12:18 -0400

Hi Matt,

Complements on updating the draft.

The issue I see is that you are attempting to distribute the CMK out of band and use "none" as the alg.

There has been a fair amount of discussion on this.  In some earlier JWE drafts before mandatory integrity you could directly encrypt/decrypt with the out of band shared secret.

Based on JSMS and mandatory integrity we adopted having a CMK always included in the message to allow for rotation.  
From a implementation point of view the symmetric cypher always gets the CEK derived from the CMK in the message independent of if it is using RSA or A128KW/A256KW.

That imposes some extra steps for people using symmetric keys but encourages rotation of the CEK that would likely not happen otherwise.

So in your spec I would expect you to distribute a shared secret via keyreq for use in A256KW and be using that decrypt the CMK at the receiver.

I also suspect that you intended to use A256GCM as the enc alg and not A256CCM. 

I am not a XMPP expert so it will take me some time to go over it in detail.   I would like to understand the use case to be certain it is properly supported.

Regards
John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 22 Jun 2012 15:34:09 -0400

Hey John,

I think you're missing the bigger point here, which is: In order to allow for multiple recipients, Matt had to break JWE.

This is yet another reason to abandon integrity protection for cryptographic parameters.  Namely, it makes allowing for multiple recipients much harder than it needs to be.  If you integrity-protect the wrapped key, then you need to change the integrity value whenever you wrap the key for a new recipient.  In addition to increasing overhead in computing and communicating objects for multiple recipients, now you've locked yourself out of algorithms that don't have a separate integrity check value, such as AES-CCM.

--Richard

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jun 2012 17:09:32 -0600

> So in your spec I would expect you to distribute a shared secret via keyreq for use in A256KW and be using that decrypt the CMK at the receiver.

I had not fully considered that; I'll have to ponder this.

> I also suspect that you intended to use A256GCM as the enc alg and not A256CCM. 

I like real examples, and I had an implementation of CCM handy but not one for GCM (-:

I'll most likely update the examples to draft-mcgrew-aead-aes-cbc-hmac-sha2 in a future version, since I have the "pieces" to implement this; I strongly recommend the WG look at adopting this, too.

> I am not a XMPP expert so it will take me some time to go over it in detail.   I would like to understand the use case to be certain it is properly supported.

I believe Richard Barnes summed it up in his JOSE usecases[1] presentation in Paris.  There's also the presentation I did on XMPP-E2E[2] I did for Paris.

- m&m

[1] < http://www.ietf.org/proceedings/83/slides/slides-83-jose-7.pdf >
[2] < http://www.ietf.org/proceedings/83/slides/slides-83-xmpp-1.pdf >

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jun 2012 19:11:57 -0400

Hi Richard,
 
Having read Matt's spec, he is not breaking JWE to send to multiple recipients.  As the spec says:
"This document specifies an approach for encrypting communications between two entities which each might have multiple end-points"
 
I should also point out that the messages are transported in XML, and as such, the addition of a JSON wrapper for the JWE probably is not useful as it would need escaping anyway.  By not sending the CMK as part of the message, you get a small reduction in message size, but you increase the number of separate key transport messages required.   In any event it has nothing to do with integrity protecting the header.
 
There are two somewhat separate uses for JWE in the spec:  one for encrypting the messages themselves using symmetric keys, and another using asymmetric keys for requesting symmetric keys.
 
For the transmission of the messages, I can't see any reason to not use the JWE spec as currently written.   It certainly supports the use case without modification.  Matt's creative use of "none" as the algorithm is not required and likely only requires a short conversation to sort out.
 
Currently the message on the wire looks like:
 
<message xmlns='jabber:client'
            from=[email-masked]/balcony'
            id='fJZd9WFIIwNjFctT'
            to=[email-masked]/garden'
            type='chat'>
     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
          id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
       <header>
         eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
         HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX
         NpemUiOiIxNiJ9
       </header>
       <data>
         7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO
         9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41
         wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME
         KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk
         RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0
         1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O
         LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg
         g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti
         JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7
         TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD
         MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g
         E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-
         eCGP
       </data>
       <mac/>
     </e2e>
   </message>
 
I would have sent header and data as one element using the normal JWE dot separated format, but I need to talk to Matt to understand his reasoning.
 
I note that his example is using AES-CCM, and so not documented in JWA.  That isn't a big deal if we want to add it.  CCM supports extra authenticated data and outputs an authentication tag like GCM.  In CMS RFC 5084, the tag seems to be carried separately from the encrypted data and in RFC 3610, the tag is concatenated to the encrypted data.   If we want to support CCM, then we need to pick one of the ways to transport the tag info.  Either would work.   We would just need to define that the integrity element contains a zero byte string as Matt has, if we want to concatenate the integrity tag value after the ciphertext.
 
I don't quite get your point on integrity protecting the wrapped key causing the integrity value to change.   For HMAC, GCM, and I think CCM, changing the encryption key changes the tag value anyway (sort of the point I thought).  The only time it would stay the same would be if you were just using a MAC over the body and that is a touch useless for integrity protection.  Perhaps I am missing the point, but as far as I know even without protecting the header, the tag value is different for every key (and nonce/IV).
 
There are some interesting things Matt’s spec is attempting with using asymmetrically encrypted/signed JWE/JWS as a key transport protocol.   I need to go through that more closely.
 
I am happy to work with Matt to refine his ID.
 
I recommend others read it as well so we can understand if there are any real issues.
 
Regards
John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jun 2012 19:37:46 -0400

Hi Matt,

No problem with using CCM, but it is not one of the supported algorithms yet so where to put the tag needs to be defined.  That seems to vary between implementations from what I can see.
That can be sorted out if it gets added.

From Richard's presentation he has a single message going to multiple recipients, but in your spec and presentation I only see two party symmetric key encryption/decryption with the shared keys distributed via the key request mechanism.

Perhaps you can point me to an example of two endpoints with different keys receiving and decrypting the same message.   

One possible way to make things simpler would be to not bother with distributing the symmetric keys separately.

You could have the receiver send it's public key to the sender as you do now, but use that to RSA encrypt the CMK in each JWE.  
There may be good reasons you have for not doing that.   If you are coming to IETF in Vancouver perhaps we could whiteboard some options.

Also as you are sending the JWE in XML you could just leave it as one dot separated value.   Is there some reason you want the header in a separate XML element?

I see that you are sending the keyid as part of the e2e element, that is not a problem, though normally that would be in the header.

The other thing to consider is using a static-static key agreement mechanism. 

There are a bunch of trust issues that I probably need to understand better in your use case.

Regards
John B.

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jun 2012 17:41:36 -0600

> I would have sent header and data as one element using the normal JWE dot separated format, but I need to talk to Matt to understand his reasoning.

The original rationale for not using dot-separated was because originally (-00) I needed to parse the header before decrypting, to determine what was missing.  With the newer version (-01), it might not still be necessary.

> I note that his example is using AES-CCM, and so not documented in JWA.  That isn't a big deal if we want to add it.  CCM supports extra authenticated data and outputs an authentication tag like GC…

I personally don't care either way.  At one point CCM was mentioned on the list, so there might be desire there beyond my example.

> There are some interesting things Matt’s spec is attempting with using asymmetrically encrypted/signed JWE/JWS as a key transport protocol.   I need to go through that more closely.

I'll add the rationale to my next version.  I think the presentations in Paris by Richard (in JOSE) and myself (in XMPP) spell it out; in a nutshell, a single message to a recipient (read: end user) can be routed/multiplexed to multiple endpoints (resources in XMPP nomenclature), including instances the sender is not aware of at the moment of transmission.

> I recommend others read it as well so we can understand if there are any real issues.

Suggestions and feedback are appreciated!

- m&m

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jun 2012 19:00:30 -0400

Hi Richard,

 

 

 

 
 
Regards
John B.

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jun 2012 18:16:05 -0600

On Jun 22, 2012, at 18:01, John Bradley wrote:

> Sorry I sent this at the same time your reply went out.
> 
> So let me know if I have this correct:
> 1 sender creates key and keyid.
> 2 Sender encrypts message with key (or derived key) 
> 3 Sender sends message 
> 4 XMPP server distributes message to n endpoints (resources).
> 5 one or more endpoints send there public key in key request messages to sender based on the received keyid.
> 6 sender sends back key encrypted with endpoint's public key to endpoint.
> 7 endpoint decrypts keyrequest and gets shared secret
> 8 endpoint decrypts message with shared secret.
> 

That is the flow.  I'll make that explicit in a future version of -xmpp-e2e.

> So the message to the endpoint arrives before the key negotiation.   Now I see why the client is requesting the symmetric key.
> I will think about it.    I don't see anything on the face of it that should be an issue with JWE.
> 
> I don't quite get what stops an intermediate node from intercepting the message and asking for the key, so there is more I need to learn.
> 

In XMPP, there's a certain amount of trust users put into their servers.  In SMTP it would be relatively trivial for Richard to send you messages as me; In XMPP the bar is higher.

Note that endpoint here means a specific resource for a user.  The intent here is the message is sent to a single user, but could be multiplexed by the server to multiple clients for that user.

Also, nothing stops a client from rejecting a keyreq because of some outside factor (e.g. third-party clearing house, existing CA infrastructure, etc).

I will be in Vancouver, and would be happy to explain more about XMPP.

> Thanks for the response.
> John B.
> 
> On 2012-06-22, at 7:41 PM, Matt Miller wrote:
> 
>> 

- m&m

---

From: Mike Jones <[email-masked]>
Date: Sat, 23 Jun 2012 01:47:44 +0000

I'd be glad to be part of the XMPP discussion as well to better understand your use case.  See you in Vancouver...

-- Mike

________________________________
From: Matt Miller
Sent: 6/22/2012 5:17 PM
To: John Bradley
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-01.txt

- m&m

---

From: John Bradley <[email-masked]>
Date: Sat, 23 Jun 2012 20:45:31 -0400

Thanks for the response.
John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jun 2012 19:02:07 -0400

Richard,

There was some other back and for with Matt.

He is only encrypting to one recipient at a time.

Not that encrypting the CMK to multiple recipients is not valid,  that is just not how the protocol works.

The message is encrypted once and whatever endpoint gets it calls back to the sender to get the key.

The issue as I understand it is that the sender doesn't know the public key for the recipient before it sends the message.

I am happy to work on Matts issues, but I think they are separate from the point you are making on integrity protecting the header.

John B.

On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote:

> He isn't a JWE-provided facility for addressing to multiple recipients; he had to roll his own.  He shouldn't have to; the JOSE format should support that.
> 
> Compare JSMS and the WrappedKey structure, or CMS and RecipientInfo.
> <http://tools.ietf.org/html/draft-barnes-jose-jsms-00#section-4.6.3>
> <http://tools.ietf.org/html/rfc5652#section-6.2>
> 
> 
> Valid point.  I had missed that RFC 5084 handled the ICV separately.
> 
> 
> The point is that you have to re-compute the ICV over the entire header+content every time you wrap a new key.  This is kind of a big deal for the XMPP case.  
> 
> Imagine I send a long message in Matt's system:  With integrity protection on the parameters, the XMPP entity doing the wrapping has to cache the entire header and message (alongside the CMK), and reprocess the whole thing when somebody asks for a key.   Without it, all I need cache is the message ID and CMK, and just re-wrap the CMK when someone asks.  For big messages, we're talking orders of magnitude more state.  And in addition, it has to cache the message in *plaintext*, which creates serious operational security risks.
> 
> So integrity protecting the headers has real costs in terms of both scalability (state) and security.
> 
> 
> My point is that we shouldn't need a whole new protocol for this.  CMS RecipientInfos do exactly what we want.  (Er, what *Matt* wants.)  We should just be copying and pasting.
> 
> --Richard
> 
> 
> 
> 
> 
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 13:25:20 -0400

I think we agree about what Matt's document is doing.  To summarize:

Sender -> Receiver: { alg: none, enc, iv } [protected body]
Receiver -> Sender:  <keyreq> <kid/> <pkey/> </keyreq>
Sender -> Receiver: { kid, alg } [encrypted CMK]

(Note that technically, this document doesn't use JWE at *all*, since at no point in the protocol is there an actual JWE-encoded object.)

This has a lot to do with integrity protection, actually.  What the above scheme does is remove all JWE header parameters besides "alg" and "enc" from integrity protection.  So, for example, there's no integrity protection on the "kid", "jwk", or "x5t" parameters, nor for the JWE Encrypted Key.  

Are you OK with that?  Would you be OK with a variant in which the initial JWE had no header at all?  After all, the recipient can actually use the parameters until it does the <keyreq> transaction.

BTW, Matt: If I were designing this, I would simplify it even further:

Sender -> Receiver: [encrypted content]
Receiver -> Sender: <keyreq> <kid/> <JWK/> </keyreq>
Sender -> Receiver:
{
    version: 1,
    type: "encrypted",
    algorithm: [algorithm],
    mac: [ICV],
    keys: [WrappedKey for kid]
}

As I mentioned above, there's no reason to send the algorithms on the first shot, since the recipient can't use them anyway.  This way, the recipient can just toss the encrypted content into the "content" field of the JSMS object, then process it like normal.  

Alternatively, you could provide a whole JSMS EncryptedData object on the first shot, with WrappedKeys for keys you know.  Then, if a recipient doesn't find a WrappedKey for himself, he can <keyreq> for it, and you can just respond with the WrappedKey.

--Richard

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 15:22:49 -0400

> <snip>

> Alternatively, you could provide a whole JSMS EncryptedData object on the first shot, with WrappedKeys for keys you know.  Then, if a recipient doesn't find a WrappedKey for himself, he can <keyreq…
That is what I was trying to get at.  The existing spec supports sending the wrapped content key with a keyid.

You send that with every message,  if the recipient doesn't have the necessary key it requests it.

The receiver retrieves the key and unwraps the CMK.   There is nothing in the current spec that stops that from working.

The message and integrity are based on the wrapped key.   That is the decision the WG took a while ago.

Having multiple recipients each with a different symmetric or asymmetric key used to wrap the CMK is slightly different problem.

Jim's proposal for having multiple recipients in the header has potential,  I don't support everything in it but it contributes some useful ideas to support multiple recipient and signature use cases.

John B.

---

From: Matt Miller <[email-masked]>
Date: Tue, 26 Jun 2012 13:26:23 -0600

> Jim's proposal for having multiple recipients in the header has potential,  I don't support everything in it but it contributes some useful ideas to support multiple recipient and signature use cas…

Allow me to work on a version of xmpp-e2e that uses "alg":"A128KW" (or "A256KW"), and see what it looks like.  I have a couple of other drafts to get done before the -00 deadline, but I should get back to this before 07/09.

- m&m

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 15:30:49 -0400

> Having multiple recipients each with a different symmetric or asymmetric key used to wrap the CMK is slightly different problem.

Obviously, JWE key wrapping works for single recipients.  I don't contest that.  Multiple recipients is the problem.  

Unless you want to support multiple recipients, there's no point to Matt's scheme.  It's tempting to think that it addresses the case where the sender doesn't know the single recipient's key in advance, but in that case, it would be much simpler just to have the sender request the key at the start.  So the whole point of Matt's document is to support multiple recipients, at the cryptographic layer, even if not at the XMPP layer (a given JID might have multiple keys, e.g., per device).

Anyway, you skipped the important question in my mail: Do you think that Matt's scheme compromises the security of the JWE?

--Richard

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 16:58:46 -0400

I would prefer to let Matt update his spec before further dragging him into this.

I have always been for having multiple recipients,  I raised the issue with JWE before the JOSE work group.

I just want to do that without overly complicating the simple case.

The question is how to do it.   I and others prefer maintaining the integrity protection over both the header and content.  
I prefer to find a way to have both integrity and multiple recipients.

As I stated Jim's proposal has some good ideas and doesn't require scrapping integrity.

I appreciate that you are approaching this from the CMS perspective,  though the correct thing to do in CMS with integrity protecting attributes in CMS seems to also have multiple opinions.

Regards
John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 17:13:35 -0400

You still haven't answered my question: Does Matt's document, as is, compromise the security of JWE?

> I prefer to find a way to have both integrity and multiple recipients.

As I've noted previously, you can have integrity and multiple recipients, but it costs you something:
-- Efficiency: 
    -- You have to re-process the entire message body for every recipient, not just the key
    -- The message has to carry separate base64url-encoded headers for each recipient
    -- The recipient has to decode each header to figure out which is his
-- Scalability: 
    -- If you want to be able to add a recipient later, you have to cache the whole message
-- Security: 
    -- If you want to be able to add a recipient, you have to cache the message in plaintext
    -- Prefixing the signed body with a header creates vulnerabilities to prefix-based attacks

Some of these get better if you use canonicalization instead of base64url-encoding, but given that nobody has yet articulated a clear benefit, I'm not sure why it's worth the trouble.

> I appreciate that you are approaching this from the CMS perspective,  though the correct thing to do in CMS with integrity protecting attributes in CMS seems to also have multiple opinions.

I'm happy to support header integrity as an *optional* mechanism.  (Indeed, there's no way you can prevent someone from, say, copying headers in the body to integrity-protect them.)  I just don't think it should be *mandatory*.  If you want to mandate it for JWT, that's fine.  But it shouldn't be required in the general-purpose format.  

--Richard

---

From: Matt Miller <[email-masked]>
Date: Tue, 26 Jun 2012 15:18:03 -0600

/me ignores thread until next update is submitted

- m&m

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Jun 2012 13:15:39 -0400

Richard,

Matt's spec used some elements from JWE but violated the JWE spec in several ways.  
It is a early draft so I am not criticizing it, as a draft it served a purpose in generating comments.

We have both made suggestions on how it could be improved.  

Security is quite often not a binary issue,  any algorithm can be compromised given enough time.
The question is how much time and effort t is required by an attacker.

Integrity protection of the header arguably raises the bar for an attacker in many situations (perhaps not all).

Matt could have easily integrity protected the header by including it in the Additional Authenticated Data (AAD) for AES-CCM.

The integrity protection over the header would not have compromised anything else in the spec as far as I can see.

Regards
John B.

On 2012-06-27, at 7:21 AM, Richard L. Barnes wrote:

> I'll stop bothering you on list after this round, but this really is the crucial question.
> 
> If you think that header protection is a required security mechanism, then Matt's document is insecure.
> 
> If you think Matt's document is secure, then header protection should not be required.
> 
> --Richard
> 
> 
> 
> 
>> 
>>