Re: [Cfrg] What Algorithm information needs to be authenticated?

> Why even discuss these? What is wrong with the answer "all parameters should be protected"?

Indeed, "all parameters should be protected" is the security posture taken in the current JOSE specifications.  Some want to change that.

				-- Mike

-----Original Message-----
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Ben Laurie
Sent: Friday, April 05, 2013 2:56 PM
To: Jim Schaad
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] What Algorithm information needs to be authenticated?

On 4 April 2013 07:25, Jim Schaad <ietf@augustcellars.com> wrote:
> Request for Information
>
> The JOSE working group is having an internal argument about the need 
> to protect the various header information in an encrypted or signed message.
> The quick question is which algorithm information and algorithm 
> parameters need to be included in integrity portion of the signature 
> or encryption operation in order to protect those parameters.
>
> There are a couple of theoretical attacks that can be launched against 
> various algorithms that then require protection an example of such a 
> parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed.
> In this case the IV is protected by the algorithm itself and therefore 
> does not need to be externally protected by the JOSE data structures.
>
> In RFC 6211, there is a new CMS attribute that was defined for 
> protection of the signature algorithm as I felt there was a potential 
> attack that could be exploited.
>
> Looking at the RSA v1.5 signature algorithm, one cannot change the 
> hash algorithm as the hash algorithm is encoded as part of the padding 
> for the signature
>
> Looking at the RSA PSS signature, there is the possibility that a hash 
> algorithm of the same length could be substituted unless external 
> restrictions are applied.  Thus one could potentially substitute a
> RIPEMD-160 hash on the content for a SHA-1 hash.   As long as the hashes
> match and there is no externally applied restriction that the hash 
> algorithm used to build the PSS internals is same as the content hash 
> then it would verify.  It is unclear if there is an attack that 
> involves multiple hash algorithms that is better than a birthday 
> attack on a single algorithm as I don't know if this has ever been studied.
>
> CMS also defined an attribute that can be included in the signature 
> computation for specifying a certificate that is to be used in the 
> validation of the signature on the CMS object.  I.e. where to get the 
> public key and the base restrictions for that are imposed on that 
> public key by the certificate issuer.
>
> Questions that we would like to see discussed:
>
> 1.  For signature operations, what parameters related to the signature 
> algorithm and what parameters related to a key need to be protected by 
> the signature operation to prevent real and theoretical attacks on JOSE signed
> structures.   We would like to get the real and theoretical attacks
> separated with a weight on the theoretical attacks for the potential 
> to become real.
>
> 2.  For MAC operations, what parameters related to the MAC algorithm 
> and what parameters related to the key need to be protected by the MAC 
> operation to prevent real and theoretical attacks on a JOSE MAC structure.
>
> 3.  For key management operations (how the content encryption key is 
> given to the recipient), what parameters related to the algorithms 
> need to be protected as part of the AEAD algorithm.
>
> 4.  For content encryption, what parameter related to the AEAD 
> algorithm need to be protected by the AEAD algorithm (and are not 
> already protected) need to be included.  Is there any benefit in 
> double protecting parameters such as the IV in case a new AEAD 
> algorithm does not directly protect that value.

Why even discuss these? What is wrong with the answer "all parameters should be protected"?

> Looking at the key to be protected, we don't care if the recipient 
> cannot find the correct key or misinterprets what the key identifier 
> is.  What we want to make sure is that an attacker would be unable to 
> change the recipients interpretation of what key is to be used and 
> still get a successful validation.
>
> Jim Schaad
> JOSE Co-Chair
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg