Subject: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

From: Malla Simhachalam <[email-masked]>
Date: Thu, 16 Jul 2015 15:33:31 -0700

Hi,

I am looking at the spec
https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining JWS
and JWE use case, I could not find it obvious that a JSON document should
be signed first and then encrypt or other way around.Are there any
recommendations one over the other?

Thanks for help.
Malla

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Jul 2015 23:45:06 +0100

https://tools.ietf.org/html/rfc7519#section-11.2 <https://tools.ietf.org/html/rfc7519#section-11.2>

It is in the JWT spec.   You can do it both ways however you really need a good reason not to sign then encrypt, and then after you have a good reason you should still sign then encrypt because you probably have not considered everything,

There are probably some edge cases that are exceptions to the rule, but they are rare.

John B.

> On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <[email-masked]> wrote:
> 
> Hi,
> 
> I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1 <https://datatracker.ietf.org/doc/rfc7520/?include_text=1> for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other?
> 
> Thanks for help.
> Malla
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Nat Sakimura" <[email-masked]>
Date: Fri, 17 Jul 2015 15:26:53 +0900

Hi Malla, 

Just to add one more thing: 

If you just want to "sign" for the sake of integrity protection, you really
do not need to do it as all the algs in JWE are integrity protected. 

-- 

Nat Sakimura < <mailto:[email-masked]> [email-masked]>

Nomura Research Institute, Ltd. 

PLEASE READ:

The information contained in this e-mail is confidential and intended for
the named recipient(s) only.

If you are not an intended recipient of this e-mail, you are hereby notified
that any review, dissemination, distribution or duplication of this message
is strictly prohibited. If you have received this message in error, please
notify the sender immediately and delete your copy from your system.

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:45 AM
To: Malla Simhachalam <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

https://tools.ietf.org/html/rfc7519#section-11.2

It is in the JWT spec.   You can do it both ways however you really need a
good reason not to sign then encrypt, and then after you have a good reason
you should still sign then encrypt because you probably have not considered
everything,

There are probably some edge cases that are exceptions to the rule, but they
are rare.

John B.

On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <[email-masked]
<mailto:[email-masked]> > wrote:

Hi,

I am looking at the spec
https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining JWS
and JWE use case, I could not find it obvious that a JSON document should be
signed first and then encrypt or other way around.Are there any
recommendations one over the other?

Thanks for help.

Malla

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Jul 2015 06:09:15 -0700

Though you want to be careful with that as the asymmetric algs in JWE don't
provide authentication of the sender.

On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura <[email-masked]> wrote:

> If you just want to “sign” for the sake of integrity protection, you
> really do not need to do it as all the algs in JWE are integrity protected.
>
>
>
> --
>
> Nat Sakimura <[email-masked]>
>
> If you are not an intended recipient of this e-mail, you are hereby
> notified that any review, dissemination, distribution or duplication of
> this message is strictly prohibited. If you have received this message in
> error, please notify the sender immediately and delete your copy from your
> system.
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Friday, July 17, 2015 7:45 AM
> *To:* Malla Simhachalam <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens
>
>
>
> https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining
> JWS and JWE use case, I could not find it obvious that a JSON document
> should be signed first and then encrypt or other way around.Are there any

---

From: John Bradley <[email-masked]>
Date: Fri, 17 Jul 2015 15:02:04 +0100

They provide integrity protection for the encryption,  that is very important for preventing padding oracle attacks.

AES GCM <https://tools.ietf.org/html/rfc7518#section-5.3> and AES_CBC_HMAC_SHA2 <https://tools.ietf.org/html/rfc7518#section-5.2> are both examples of Authenticated Encryption <https://en.wikipedia.org/wiki/Authenticated_encryption> in the sense that the received encryption is true and not that the sender is identified.

English speakers have a hard time with the subtle difference between identification and authentication , so I wanted to be clear.

That being said there is a special case where if the JWT ie encrypted with a symmetric key known only to two parties and it is “authenticated” and you didn’t create it, then by a process of elimination it cold have only come from one party.   This is NOT a signature,  however it is a useful trick that some people use to only encrypt and while still knowing with relative certainty who encrypted it.

I should note that ECDH-SS rfc6278 a key agreement algorithm we didn’t put in the base JWA spec also has the property of providing encryption and authenticity based on the  public keys of both sender and receiver.
(note this is easier for implementers to get wrong than ECDH-ES but that is another debate:)

Probably more than you wanted to know, but Nat started it:)

John B.

> On Jul 17, 2015, at 2:09 PM, Brian Campbell <[email-masked]> wrote:
> 
> Though you want to be careful with that as the asymmetric algs in JWE don't provide authentication of the sender. 
> 
> On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Malla, <>
>  
> 
> If you just want to “sign” for the sake of integrity protection, you really do not need to do it as all the algs in JWE are integrity protected.
> 
>  
> 
> --
> 
> Nat Sakimura <[email-masked] <mailto:[email-masked]>>
> 
> The information contained in this e-mail is confidential and intended for the named recipient(s) only.
> 
> If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
> 
>  
> 
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
> To: Malla Simhachalam <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> Hi,
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 Jul 2015 16:38:54 +0000

As for “ECDH-SS rfc6278 (being) easier for implementers to get wrong than ECDH-ES” the good news about crypto is that if you get it even a little bit wrong, it doesn’t work with other’s implementations at all, so this situation tends to be self-correcting.

                                                            Cheers,
                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:02 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

AES GCM<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Km4lrYHuFSmIvYONtiusFoZEtSRoAj4Ri8udIoiA5Nk%3d> and AES_CBC_HMAC_SHA2<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IaQ9hYN4Lw5bVTXRcSwNi4RzKnojIKAAIdtf53JDBvE%3d> are both examples of Authenticated Encryption<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedia.org%2fwiki%2fAuthenticated_encryption&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eRV5xgf17IWyz0j5QwgDmubDw5rqJneMaYtCHu1CLVs%3d> in the sense that the received encryption is true and not that the sender is identified.

John B.

On Jul 17, 2015, at 2:09 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Hi Malla,

--
Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Nomura Research Institute, Ltd.

PLEASE READ:

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:45 AM
To: Malla Simhachalam <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

https://tools.ietf.org/html/rfc7519#section-11.2<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-11.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bJjUa9H%2fhsoQGfjmZEBQIyYxwZNc5Hlt%2bDzrEj%2bHG70%3d>

John B.

On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc7520%2f%3finclude_text%3d1&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9X3auySnL4XlT%2fRW%2bAOaBG5wX8jrNc82AZ0Go%2bZIruM%3d> for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other?
Thanks for help.
Malla
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jul 2015 13:37:58 -0400

Unless you’re implementing both halves with parallel wrongness, in which case you’re completely screwed and have no idea.

 — Justin

> On Jul 17, 2015, at 12:38 PM, Mike Jones <[email-masked]> wrote:
> 
> AES GCM <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Km4lrYHuFSmIvYONtiusFoZEtSRoAj4Ri8udIoiA5Nk%3d> and AES_CBC_HMAC_SHA2 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IaQ9hYN4Lw5bVTXRcSwNi4RzKnojIKAAIdtf53JDBvE%3d> are both examples of Authenticated Encryption <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedia.org%2fwiki%2fAuthenticated_encryption&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eRV5xgf17IWyz0j5QwgDmubDw5rqJneMaYtCHu1CLVs%3d> in the sense that the received encryption is true and not that the sender is identified.
>  
> On Jul 17, 2015, at 2:09 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://tools.ietf.org/html/rfc7519#section-11.2 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-11.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bJjUa9H%2fhsoQGfjmZEBQIyYxwZNc5Hlt%2bDzrEj%2bHG70%3d>
>  
> I am looking at the spechttps://datatracker.ietf.org/doc/rfc7520/?include_text=1 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc7520%2f%3finclude_text%3d1&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9X3auySnL4XlT%2fRW%2bAOaBG5wX8jrNc82AZ0Go%2bZIruM%3d> for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other?
> 
> Thanks for help.
> Malla
> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>
>  
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>
>  
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 Jul 2015 17:38:51 +0000

That’s what test vectors and interop testing are for!

From: Justin Richer [mailto:[email-masked]]
Sent: Friday, July 17, 2015 10:38 AM
To: Mike Jones
Cc: John Bradley; Brian Campbell; <[email-masked]>
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

 — Justin

On Jul 17, 2015, at 12:38 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                            Cheers,
                                                            -- Mike

John B.

PLEASE READ:

John B.

Hi,

---

From: John Bradley <[email-masked]>
Date: Fri, 17 Jul 2015 19:25:10 +0100

No the issue is the entropy that needs to be added in SS because you are not using a different ephemeral key each time.  

The security considerations covers it.   There is also the case where you are encrypting to multiple recipients that breaks sender identification.

We taled about including SS and EE, but decided to keep the alg set limited to the ones people are most likely to be deployed.    

In IoT with small messages SS may have desirable properties, however no one has asked for it yet.

I was just noting that it is one way to do it but has some real security considerations that would need addressing.

John B.

Extreme care must be used when using static-static Diffie-Hellman
   (either standard or cofactor) without the use of some per-message
   value in the ukm.  As described in [RFC5753 <https://tools.ietf.org/html/rfc5753>], the ukm value (if
   present) will be embedded in an ECC-CMS-SharedInfo structure, and the
   DER encoding of this structure will be used as the 'SharedInfo' input
   to the key-derivation function of [X963 <https://tools.ietf.org/html/rfc6278#ref-X963>].  The purpose of this input
   is to add a message-unique value to the key-distribution function so
   that two different sessions of static-static ECDH between a given
   pair of agents result in independent keys.  If the ukm value is not
   used or is re-used, on the other hand, then the ECC-CMS-SharedInfo
   structure (and 'SharedInfo' input) will likely not vary from message
   to message.  In this case, the two agents will re-use the same keying
   material across multiple messages.  This is considered to be bad
   cryptographic practice and may open the sender to attacks on Diffie-
   Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu <https://tools.ietf.org/html/rfc6278#ref-MenezesUstaoglu>] or
   other, yet-undiscovered attacks).

   It is for these reasons that Section 2.1 <https://tools.ietf.org/html/rfc6278#section-2.1> states that message senders
   SHOULD include the ukm and SHOULD ensure that the value of ukm is
   unique to the message being sent.  One way to ensure the uniqueness
   of the ukm is for the message sender to choose a 'sufficiently long'
   random string for each message (where, as a rule of thumb, a
   'sufficiently long' string is one at least as long as the keys used
   by the key-wrap algorithm identified in the keyEncryptionAlgorithm
   field of the KeyAgreeRecipientInfo structure).  However, other
   methods (such as a counter) are possible.  Also, applications that
   cannot tolerate the inclusion of per-message information in the ukm
   (due to bandwidth requirements, for example) SHOULD NOT use static-
   static ECDH for a recipient without ascertaining that the recipient
   knows the private value associated with their certified Diffie-
   Hellman value.

   Static-static Diffie-Hellman, when used as described in this
   document, does not necessarily provide data-origin authentication.
   Consider, for example, the following sequence of events:

Herzog & Khazan               Informational                    [Page 12]
  <https://tools.ietf.org/html/rfc6278#page-13>
RFC 6278 <https://tools.ietf.org/html/rfc6278>                Static-Static ECDH in CMS              June 2011

   o  Alice sends an AuthEnvelopedData message to both Bob and Mallory.
      Furthermore, Alice uses a static-static DH method to transport the
      content-authenticated-encryption key to Bob, and some arbitrary
      method to transport the same key to Mallory.

   o  Mallory intercepts the message and prevents Bob from receiving it.

   o  Mallory recovers the content-authenticated-encryption key from the
      message received from Alice.  Mallory then creates new plaintext
      of her choice, and encrypts it using the same authenticated-
      encryption algorithm and the same content-authenticated-encryption
      key used by Alice.

   o  Mallory then replaces the EncryptedContentInfo and
      MessageAuthenticationCode fields of Alice's message with the
      values Mallory just generated.  She may additionally remove her
      RecipientInfo value from Alice's message.

   o  Mallory sends the modified message to Bob.

   o  Bob receives the message, validates the static-static DH values,
      and decrypts/authenticates the message.

   At this point, Bob has received and validated a message that appears
   to have been sent by Alice, but whose content was chosen by Mallory.
   Mallory may not even be an apparent receiver of the modified message.
   Thus, this use of static-static Diffie-Hellman does not necessarily
   provide data-origin authentication.  (We note that this example does
   not also contradict either confidentiality or data authentication:
   Alice's message was not received by anyone not intended by Alice, and
   Mallory's message was not modified before reaching Bob.)

   More generally, the data origin may not be authenticated unless:

   o  it is a priori guaranteed that the message in question was sent to
      exactly one recipient, or

   o  data-origin authentication is provided by some other mechanism
      (such as digital signatures).

   However, we also note that this lack of authentication is not a
   product of static-static ECDH per se, but is inherent in the way key-
   agreement schemes are used in the AuthenticatedData and
   AuthEnvelopedData structures of the CMS.

   When two parties are communicating using static-static ECDH as
   described in this document, and either party's asymmetric keys have
   been centrally generated, it is possible for that party's central

Herzog & Khazan               Informational                    [Page 13]
  <https://tools.ietf.org/html/rfc6278#page-14>
RFC 6278 <https://tools.ietf.org/html/rfc6278>                Static-Static ECDH in CMS              June 2011

   infrastructure to decrypt the communication (for application-layer
   network monitoring or filtering, for example).  By way of contrast:
   were ephemeral-static ECDH to be used instead, such decryption by the
   sender's infrastructure would not be possible (though it would remain
   possible for the infrastructure of any recipient).

> On Jul 17, 2015, at 5:38 PM, Mike Jones <[email-masked]> wrote:
> 
> I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc7520%2f%3finclude_text%3d1&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9X3auySnL4XlT%2fRW%2bAOaBG5wX8jrNc82AZ0Go%2bZIruM%3d> for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other?
> 
> Thanks for help.
> Malla