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 <michael.jo...@microsoft.com> wrote: > > 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:oauth-boun...@ietf.org] 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 > > They provide integrity protection for the encryption, that is very important > for preventing padding oracle attacks. > > 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. > > 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 <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> 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 <n-sakim...@nri.co.jp > <mailto:n-sakim...@nri.co.jp>> wrote: > 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 <n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>> > 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:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:45 AM > To: Malla Simhachalam <mallasimhacha...@gmail.com > <mailto:mallasimhacha...@gmail.com>> > Cc: oauth@ietf.org <mailto:oauth@ietf.org> > 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> > > 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 <mallasimhacha...@gmail.com > <mailto:mallasimhacha...@gmail.com>> 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 > OAuth@ietf.org <mailto:OAuth@ietf.org> > 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 > OAuth@ietf.org <mailto:OAuth@ietf.org> > 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
