Subject: [jose] Fwd: [Cfrg] Question from JOSE working group

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 Jul 2012 14:07:02 -0400

FYI, trying to recruit some additional crypto expertise on this question.

--Richard

Begin forwarded message:

> From: "Richard L. Barnes" <[email-masked]>
> Subject: [Cfrg] Question from JOSE working group
> Date: July 2, 2012 2:00:11 PM EDT
> To: [email-masked]
> 
> Dear CFRG,
> 
> This is a request for input on a crypto question that has come up in the JOSE working group.
> 
> The question is whether there is any benefit to applying integrity protection to cryptographic parameters attached to a signed/authenticated/encrypted object.  By "cryptographic parameters" here, I mean public keys, wrapped symmetric keys, algorithm identifiers, etc.
> 
> For historical background:
> 
> CMS does not provide parameter protection [RFC5652].  The content that is signed / authenticated / encrypted is precisely the protected content (eContent).  Optionally, an application may add signed attributes.  In the case of SignedData and AuthenticatedData, if signed attributes are present, then they must include the message digest that was signed or authenticated; not a parameter, but an intermediate result.
> 
> IKE and TLS does not provide integrity protection for parameters [RFC4306][RFC5246].  Algorithm negotiation is done in parallel with key agreement in the initial phase of IKEv2   Algorithm negotiation in TLS is done in the ClientHello / ServerHello messages, which are sent before the secure channel is established.  When TLS client certificates are used, the client demonstrates its possession of the relevant private key by signing the handshake messages, which provides an integrity check on cryptographic parameters as a side-effect.  However, the parameters for this signature (the public key and signature/hash algorithms) are not protected.
> 
> PKIX is an intermediate case.  The signature algorithm used to sign / verify the certificate is included in the certificate body (under the signature) as well as ouside the signature.
> 
> Back to today:
> 
> The current draft specifications for JOSE [JWS][JWE] require integrity protection for parameters.  The creator of an object constructs a "header" value including the cryptographic parameters used to generate the object.  This header value is prepended to the protected content before the content is signed / authenticated (JWS), or attached as "Associated Data" to the encrypted content (JWE).  (JWE only allows AEAD algorithms.)
> 
> So the questions for this group are the following: 
> -- Does applying integrity protection to cryptographic parameters result in a meaningful increase the security of an secure object format?  
> -- What are the classes of attack that this integrity protection would address?
> -- Does parameter protection create any additional security vulnerabilities?
> 
> Any input would be very helpful for the group to decide on a way forward.
> 
> Thanks a lot,
> --Richard
> 
> 
> [RFC5652] <http://tools.ietf.org/html/rfc5652>
> [RFC4306] <http://tools.ietf.org/html/rfc4306>
> [RFC5246] <http://tools.ietf.org/html/rfc5246>
> [RFC5280] <http://tools.ietf.org/html/rfc5280>
> [JWS] <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>
> [JWE] <http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption>
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Ben Adida <[email-masked]>
Date: Mon, 02 Jul 2012 11:21:20 -0700

My take: yes, there is value. The crypto parameters will trigger 
different processing on the payload, and that *might* be usable, by some 
crafty cryptanalyst, as an oracle.

It would be more conservative (and thus safer) to follow one rule: there 
are only two execution paths that can be triggered by the recipient of a 
crypto blob. (1) error, or (2) processing of payload according to 
authenticated sender's specifications.

-Ben

On 7/2/12 11:07 AM, Richard L. Barnes wrote:
>> From: "Richard L. Barnes"<[email-masked]>
>> [RFC5652]<http://tools.ietf.org/html/rfc5652>
>> [RFC4306]<http://tools.ietf.org/html/rfc4306>
>> [RFC5246]<http://tools.ietf.org/html/rfc5246>
>> [RFC5280]<http://tools.ietf.org/html/rfc5280>
>> [JWS]<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>
>> [JWE]<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption>
>>
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Mon, 2 Jul 2012 18:21:20 +0000

You should reply-all into the cfrg thread, saying that XMLDSIG does integrity protect the algorithm and other parameters, since you're giving them other examples of choices made by systems.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Monday, July 02, 2012 11:07 AM
To: [email-masked]
Subject: [jose] Fwd: [Cfrg] Question from JOSE working group

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 Jul 2012 14:26:30 -0400

I'm actually not that familiar with DSig; you're welcome to comment.
--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 Jul 2012 16:05:01 -0400

Here's my analysis of the question, as it stands right now.

From what I can tell, parameter protection is at best a marginal improvement, and at worst actively harmful:
1. The possible benefits are a corner case
2. The JW* syntax increases vulnerability to chosen-prefix attacks
3. The JWE syntax creates operational risks in multiple-recipient scenarios

1. The possible benefits are a corner case

A JOSE object is defined by three main things: The algorithm A (including associated parameters), the key K, and the message M.  An attack on the integrity of a JOSE object is a transformation of these parameters and the integrity check value A(K,M) such that the attacker can create another valid integrity check value A'(K',M'), causing the recipient to accept a bogus integrity check value.  Obviously, An attack is only relevant if either the key or the message changes, since the algorithm holds no inherent meaning.  For example, in the attack
   (A,K,M)-->(A,K,M'),
the recipient would accept a bogus message under the correct key.  Under the attack
   (A,K,M)-->(A,K',M)
the recipient would accept a correct message, but under the wrong key.  There are obviously seven different attacks in this model (excluding the trivial "attack"). 

There is value in parameter protection only in cases where an attacker can mount a successful attack against an object with unprotected parameters, but cannot attack an object with protected parameters.  So we should examine each of the seven different types of attacker capabilities here and see whether they extend to protected objects.

From the perspective of this model, the impact of adding integrity protection on the parameters is to add them to the message M.  So we can immediately note that parameter protection is useless against the four attacks in which the message M is modified.  If the attacker can change the protected content, then he can also change the protected parameter values, since they are, aftera all, just more content octets.

We can also ignore the two attacks where neither the key K nor the message M changes, since these don't represent a meaningful attack.

So the only possible benefit is from the two remaining cases where the key changes, but the message does not.  That is, parameter protection has value only if one of the following implications is *false*:
(1) (A,K,M)-->(A,K',M)  ==>  (A,K,M)-->(A,K',M')
(2) (A,K,M)-->(A',K',M) ==>  (A,K,M)-->(A',K',M')
In these cases, in order to overcome the parameter integrity protection, the attacker would need to be able to modify the part of the message containing the parameters.  Only if the attacker is unable to make this modification does the protection have value. 

I don't know whether these implications are true or false in general, but there are at least some cases in which they are true.  For example:
-- Implication (1) is true for HMAC: If you can change the key, then you have effectively broken the hash function, so you should be able to change the content as well.
-- Implication (1) is true for RSA-PSS, because the security of RSA-PSS is equivalent to the factoring problem [RSAPSS]

The change of algorithm question in implication (2) is an exotic one, and AFAICT, there's not much literature on it.  ISTM most likely to arise in the context of related algorithms, e.g., elliptic curves of the same size with different parameters. (This could, of course, be mitigated by requiring named curves, one per field size!)  Other than that, it seems like the differences in mathematics would make it unlikely that a valid key for one algorithm would collide.  Of course, the assumption here is 

Summing up all of the above: Parameter protection seems to only be useful under highly constrained assumptions on attacker capabilities.

2. The JWS syntax increases vulnerability to chosen-prefix attacks

There has been a lot of press lately about Flame's use of a chosen-prefix attack against MD5 to generate bogus code-signing certificates [Flame-MD5].  In general, chosen-prefix attacks have been a fairly fruitful avenue of attack against hash functions, with MD5 clearly broken, and significant progress having been made against SHA-1 [SHA1Prefix].

In the JWS signing process, the header value is prepended to the content before the whole thing is digested and signed/authenticated.  In practice, for a given signer, the JWS header is likely to be predictable to an attacker.  So JWS has a built-in predictable prefix that can be exploited for chosen-prefix attacks.

JWS also defeats efforts that applications might make to mitigate chosen-prefix attacks.  In PKIX, for example, the recommended mitigation to MD5's weaknesses is to randomize the fields that come early in the certificate, so that the length of the available prefix is minimized [RFC4270].  In JWS, however, even if an application put unpredictable things early in the content body, the JWS signing process prepends something predictable, so the efforts of the application are for naught.  

Thus, if the JOSE format ultimately does protect parameters, then it will need to include a mandatory random element at the beginning of the protected header.

3. The JWE syntax creates operational risks in multiple-recipient scenarios

One of the major use-cases for JOSE is for encrypting messages to be received by multiple entities holding different private keys.  In this context, integrity-protecting parameters causes a couple of operational concerns, arising from the fact that the wrapped key is included under the integrity check.

First, if there is any delay between the sending of the original object and the transmission of wrapped keys, then the sender needs to cache the entire object and re-process it to compute a new integrity  check value whenever a new recipient is added.  Moreover, the object needs to be cached in plaintext, exposing it to risks of being stolen on the originating host while it resides in cache.

By contrast, without parameter protection, only the encryption key needs to be cached; the content itself can be deleted.  So even though there is a risk that the cached key will leak, it can at least be separated from the protected content, to reduce the ultimate risk that the content will be exposed.

Reference:
[RSAPSS] <http://eprint.iacr.org/2001/053/>
[Flame-MD5] <https://documents.epfl.ch/users/l/le/lenstra/public/papers/lat.pdf>
[SHA1Prefix] <http://omploader.org/vNDA0cQ/SHA1CollisionsMeaningful.pdf>
[RFC4270] <http://tools.ietf.org/html/rfc4270>

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 17:00:43 -0400

Richard,

Chosen-prefix attacks require the text of both messages to be the same up to the point where the attacker can insert the collision function blocks.

If the header is not integrity protected the attacker is able to insert collision function blocks at the start of the plan text.   I have a hard time seeing the attacker controlling the entire plaintext as "better" in any way.

If anything JWS and JWE should be including a nonce or timestamp in the header to prevent this attack.   That requires integrity protecting the header with the nonce.

JOSE was constructed to make no assumptions about the plaintext.  Saying the protocol using JOSE should deal with it in the plaintext is not all that useful if arbitrary bodes are allowed for signing and encrypting.

That is one reason CMS allows for the integrity protect of additional attributes.

Regards
John Bradley

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 18:40:03 -0400

Yes sorry JOSE would not be susceptible to chosen prefix unless we allow the attacker to control the entire plaintext.
As it is now the header is controlled by the signer.

I think Richard was referring to an identical prefix attack being possible due to the header without a nonce or date stamp being relatively deterministic.

In ether event integrity protecting the header is not increasing the vulnerability.

Thanks few the correction.

Regards
John Bradley

On 2012-07-02, at 6:19 PM, Weger, B.M.M. de wrote:

> Hi John,
> 
>> Chosen-prefix attacks require the text of both messages to be the same up
>> to the point where the attacker can insert the collision function blocks.
> 
> Correction: 
> It's identical-prefix attacks that require the text of both messages to be 
> the same up to the point where the attacker can insert the collision blocks.
> That's exactly why these attacks are called "identical-prefix".
> 
> Chosen-prefix attacks allow the attacker to choose whatever he wants in
> each of the two messages up to the point where ... etc.
> 
> Chosen-prefix attacks fail if the attacker has no sufficient control over / 
> cannot sufficiently predict this part of the messages.
> 
> Grtz,
> Benne de Weger

---

From: "Weger, B.M.M. de" <[email-masked]>
Date: Tue, 3 Jul 2012 00:19:20 +0200

Hi John,

Correction: 

Grtz,
Benne de Weger