Re: [Cfrg] [jose] Question from JOSE working group

John Bradley <ve7jtb@ve7jtb.com> Mon, 02 July 2012 21:00 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C611E8126 for <cfrg@ietfa.amsl.com>; Mon, 2 Jul 2012 14:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level:
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPcYWlLQwBn1 for <cfrg@ietfa.amsl.com>; Mon, 2 Jul 2012 14:00:49 -0700 (PDT)
Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5702011E8125 for <cfrg@irtf.org>; Mon, 2 Jul 2012 14:00:49 -0700 (PDT)
Received: by ggnm2 with SMTP id m2so5420474ggn.13 for <cfrg@irtf.org>; Mon, 02 Jul 2012 14:00:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fzwH74rjM6ItPpQlPsp/w3h7yB88b5FwALlmXFB2Z0Q=; b=ZK7Zm2E9xc9yFPLm0u4v+AglY1a1EHcEeOo6hANkem/V8kN3UZ2IDiviO/h3jrWwc4 4/s1bAQjBIdaI8EMIRZGcOWPTruJtjtfJ0/mBHSx0Hy4yTyxMVxKFvCip+7B3Jsx+c1f a6ztnaEZZ8kW0eDv0R50OL5wkLPTyS+pMnkE7Jq0KiY5F/Zd10sEMTAAOKMl6SjobgNK faImzJ5rYBgB5MyRACktZp+oPTt0qjBOCT7C1U/8VWaRVF3VYkEZn1GQeYPbyWW9ZKYJ qBsKT3v3dMIXOXrARO7esHOX6km/u/jNjCTTwCNpGWm/CNHSC6ZhSkS8kSoOJHZeoh/K ZpNQ==
Received: by 10.236.181.71 with SMTP id k47mr11483069yhm.69.1341262854613; Mon, 02 Jul 2012 14:00:54 -0700 (PDT)
Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id p14sm12672864ani.8.2012.07.02.14.00.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 14:00:53 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com>
Date: Mon, 02 Jul 2012 17:00:43 -0400
Message-Id: <A010F653-8437-4725-8F8D-B2A496061A78@ve7jtb.com>
References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlexyYdN7hdokAiMlXPsTy5XddPCgz2mCVDFerPX3DYhCAUC/mqO2lM1HxTXGgG6oYFsHZJ
Cc: cfrg@irtf.org, jose@ietf.org
Subject: Re: [Cfrg] [jose] Question from JOSE working group
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2012 21:00:50 -0000

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

On 2012-07-02, at 4:05 PM, Richard L. Barnes wrote:

> 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>
> 
> 
> On Jul 2, 2012, at 2:00 PM, Richard L. Barnes wrote:
> 
>> 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
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose