Subject: [jose] some more comments on the jose drafts ...

From: "Juraj Somorovsky" <[email-masked]>
Date: 11 Dec 2011 22:32:22 +0100

Hi,

I would also like to contribute with some comments to the jose drafts. I
am not following closer the jose evolution, but I hope my comments will
be useful.

1) usage of unauthenticated encryption: as already written by David, the
encryption algorithms should not be used without authentication and
integrity check. JOSE standards should not allow the usage of AES-CBC.
Otherwise, it is only a matter of time before we will see some practical
attacks.

2) usage of RSA1_5: Is it really necessary to have this algorithm in the
standard? Would it not be enough to have RSA-OAEP?
The problem with RSA1_5 is that it is vulnerable to side-channel attacks
described by Daniel Bleichenbacher [1]. These attacks could be simply
mitigated in SSL or similar protocols. However, application of these
mitigation techniques in json could be more complicated and would cause
many implementation problems. Therefore, I would suggest only to use
RSA-OAEP. (there is a next attack on XML Encryption coming soon, it
describes these problems)

3) Streaming-based signature creation: I am not that familiar with json
and all its application scenarios (therefore I am sorry, if this is out
of scope). I can imagine that you want to transport a large signed
document. If you generate the document on the fly, you would probably
want to send it directly to the recipient without caching it in the
memory. However, this would not be possible using your signature
standard, as you have to put the whole document to the memory, create a
signature over this document, put this signature into the header, and
lastly send the whole file with signature headers.
As I have seen in your standard, it is not allowed to put the signature
value behind the signed document (please correct me if I am wrong).
Similar problems in SOAP messages were discussed also by Sean Mullan [2].

I hope my comments will be useful.

Best Regards
Juraj

[1] D. Bleichenbacher.  Chosen Ciphertext Attacks Against Protocols
Based on the RSA Encryption Standard PKCS #1.

[2] S. Mullan: XML Signature Performance and  One-Pass Processing Issues
http://www.w3.org/2007/xmlsec/ws/slides/01-mullan-sun/Overview.pdf

-- 
M.Sc. Juraj Somorovsky

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
-----------------------------------
Universitätsstr. 150, Geb. ID 2/411
D-44780 Bochum

Telefon: +49 (0) 234 / 32-26551
Fax: +49 (0) 234 / 32-14347
http://www.nds.rub.de

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 13 Dec 2011 01:05:31 +0900

> Otherwise, it is only a matter of time before we will see some practical

I fully agree that encryption should be used only with integrity checking.
In the ideal world, we would only have to use some mode like GCM, but
unfortunately the support is yet to become wide spread. In most platforms,
it is likely that the develop has to rely on something like CBC whose
support is much more wide spread. Under this cercumstances, we would have
to support CBC with integrity checks. So, doing encryption and integrity
check (optional for GCM etc., and MUST for CBC) is the way to go, IMHO. To
do so, instead of just using CEK, include the CMK in the header and use it
to create CEK and CIK.

> describes these problems)

As to the support of PKCS 1.5 is concerned, again, it is the same problem
as the support of GCM. The platform that only supports PKCS 1.5 is still
wide spread. Of course we may use this spec to whip the providers and
software vendors to build the support for a more decent algorithms but that
will severely limit the adoption of the spec in the initial phase. I think
we should support PKCS 1.5 as a base line which is a MUST, and strongly
recommend more decent ones and put some comment in the security
consideration as well.

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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 15 Dec 2011 19:25:53 +0100

> do so, instead of just using CEK, include the CMK in the header and use it
CBC is OK if cryptographic integrity checks (MACs) are mandatory (and if
the data is not processed before the MAC is verfied). Please do not
allow CBC without MAC.
> recommend more decent ones and put some comment in the security
Ok, I just wanted to warn you. PKCS #1 v1.5 will affect the security of
the specification and many developers will have problems to apply valid
countermeasures, which will completely mitigate the attacks.

I would rather force the old platforms to move to a secure standard
(rsa-oaep) than force the other developers to use pkcs1.5 and implement
the countermeasures.

Best Regards
Juraj
-- 
M.Sc. Juraj Somorovsky

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 16 Dec 2011 15:55:41 +0000

A lot of platforms can't as these are well deployed crypto libraries

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juraj Somorovsky
Sent: Thursday, December 15, 2011 10:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] some more comments on the jose drafts ...

On 12/12/2011 05:05 PM, Nat Sakimura wrote:
>> I would also like to contribute with some comments to the jose 
>> drafts. I am not following closer the jose evolution, but I hope my 
>> comments will be useful.
>>
>> 1) usage of unauthenticated encryption: as already written by David, 
>> the encryption algorithms should not be used without authentication 
>> and integrity check. JOSE standards should not allow the usage of AES-CBC.
>> Otherwise, it is only a matter of time before we will see some 
>> practical attacks.
>>
> 
> unfortunately the support is yet to become wide spread. In most 
> platforms, it is likely that the develop has to rely on something like 
> CBC whose support is much more wide spread. Under this cercumstances, 
> we would have to support CBC with integrity checks. So, doing 
> encryption and integrity check (optional for GCM etc., and MUST for 
> CBC) is the way to go, IMHO. To do so, instead of just using CEK, 
> include the CMK in the header and use it to create CEK and CIK.
CBC is OK if cryptographic integrity checks (MACs) are mandatory (and if the data is not processed before the MAC is verfied). Please do not allow CBC without MAC.
> 
> 
>> 2) usage of RSA1_5: Is it really necessary to have this algorithm in 
>> the standard? Would it not be enough to have RSA-OAEP?
>> The problem with RSA1_5 is that it is vulnerable to side-channel 
>> attacks described by Daniel Bleichenbacher [1]. These attacks could 
>> be simply mitigated in SSL or similar protocols. However, application 
>> of these mitigation techniques in json could be more complicated and 
>> would cause many implementation problems. Therefore, I would suggest 
>> only to use RSA-OAEP. (there is a next attack on XML Encryption 
>> coming soon, it describes these problems)
>>
> 
> As to the support of PKCS 1.5 is concerned, again, it is the same 
> problem as the support of GCM. The platform that only supports PKCS 
> 1.5 is still wide spread. Of course we may use this spec to whip the 
> providers and software vendors to build the support for a more decent 
> algorithms but that will severely limit the adoption of the spec in 
> the initial phase. I think we should support PKCS 1.5 as a base line 
> which is a MUST, and strongly recommend more decent ones and put some 
> comment in the security consideration as well.
Ok, I just wanted to warn you. PKCS #1 v1.5 will affect the security of the specification and many developers will have problems to apply valid countermeasures, which will completely mitigate the attacks.

I would rather force the old platforms to move to a secure standard
(rsa-oaep) than force the other developers to use pkcs1.5 and implement the countermeasures.

Best Regards
Juraj
--
M.Sc. Juraj Somorovsky

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Dec 2011 04:50:35 -0800

> the data is not processed before the MAC is verfied). Please do not

I concur with this.

> countermeasures, which will completely mitigate the attacks.

Hmm... Can you explain what you think the issue is that makes it hard to
deploy countermeasures?

-Ekr

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 20 Dec 2011 14:28:56 +0100

> Hmm... Can you explain what you think the issue is that makes it hard to
To be honest, I have now took a look at your draft from 2001
(http://tools.ietf.org/html/draft-ietf-smime-pkcs1-01). Actually, you
describe all the mitigation problems and attack possibilities.

I agree with you that generating of a random CEK is a valid
countermeasure, if CMK is not pkcs1 conform. However, as you already
mentioned in Section 2.2.1, this is not a 100% valid countermeasure if
the attacker can force the server to use CBC without HMAC checking. The
attacker could simply generate 256 messages with a different last
initialization vector byte. If CMK was pkcs1 conform, one of the
messages will result into a 0x01 padding, the decrypted message gets
valid, and the attacker gets a different response from the server, which
makes it possible to apply the Bleichenbacher attack. This attack would
be 256-times slower than the original one. However, please note that
there are also CMKs, which do not necessarily need to issue 1000 000
messages, even if a strict checking of pkcs1 is used (0x00 0x02 ....
0x00 CEK).

If CEK would not be randomly generated (which will probably be the case
in most of the libraries), the adversary could also apply this attack if
the server strictly uses CBC with HMACs. For this purpose, he makes the
message text as long as he want and considers timing.

I mean that there are still many libraries that did not consider the
Bleichenbacher attack or applied wrong countermeasures. If they want to
be secure, they still need to reimplement these countermeasures and
change their frameworks. This could become pretty difficult in the future.

Regards
Juraj

-- 
M.Sc. Juraj Somorovsky