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

From: Russ Housley <[email-masked]>
Date: Mon, 2 Jul 2012 15:43:20 -0400

In the CMS signature processing, the hash algorithm is covered by the signature.  The hash algorithm is a signed attribute, and the collection of signed attributes is hashed as part of the signature process.

Other parameters of the signature algorithm, if any, are not integrity protected.  The thinking is that the signature algorithm is seriously flawed is a change to the parameters will make an invalid signature seem valid.

Russ

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

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

_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

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

Actually, the inclusion of the hash algorithm under the signature is optional:
"
      signedAttrs is a collection of attributes that are signed.  The
      field is optional, but it MUST be present if the content type of
      the EncapsulatedContentInfo value being signed is not id-data.
      [...]  If the field is present, it MUST
      contain, at a minimum, the following two attributes:

         ...

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.
"

Since "id-data" means "no more ASN.1 structure", for JOSE, the content type is effectively always "id-data".

--Richard

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Jul 2012 11:01:46 -0400

> Since "id-data" means "no more ASN.1 structure", for JOSE, the content type is effectively always "id-data".

In practice, there are other attributes that one wants signed, such as signing-time, so the algorithm identifier gets included.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2012 10:43:51 -0700

I would also note that when PKCS#7 was designed, the hash algorithm was
always protected independent the presence of signed attributes.  Either the
hash algorithm was in the signed attributes or it was in the RSA signature
block encoding.   It was only with the introduction of other algorithms that
this was no longer true.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Russ Housley
> Sent: Tuesday, July 03, 2012 8:02 AM
> To: Richard L.Barnes
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Cfrg] Question from JOSE working group
> 
> Richard:
> 
> In practice, there are other attributes that one wants signed, such as
signing-
> time, so the algorithm identifier gets included.
> 
> Russ
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 3 Jul 2012 15:58:31 -0400

More precisely:
RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature
RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash algorithm

Doesn't this seem to argue against the need to protect parameters, since the security of RSASSA-PSS is tightly related to the RSA problem itself?

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2012 14:28:16 -0700

As I said - with the introduction of new signature algorithms led to the
fact that the hash algorithm was no longer protected.

If you are looking at breaking an RSA signature, you have two ways of going
about it.  You can either break the hash in some way - or you can factor the
RSA keys.   The RSA problem is related to the factoring of the keys and has
little to do with attacking the hash algorithm.

If I could get you to substitute my hash algorithm for the actual hash
algorithm used, and they had the same hash value for different messages then
the RSA problem is not relevant for the purposes of the attack.  The
PKCS#1.5 RSA defended against this by placing the hash algorithm identifier
in as part of the "to be signed" value.  This was both good - the hash
algorithm was defended and bad - there were lots of known bits fixed bits in
the signature block for lots of signatures.

There can be operational/convention steps that deal with this - for example
there is a suggested practice that the hash algorithm used in the RSA-PSS
signature operation and the one computing the hash of the message should be
the same.  But there is no current requirement that these steps be followed.
(Oops - need to file an erratum on RFC 4056 about what to do for a hash
algorithm if signed attributes are not used.)

The reason for writing RFC 6211 was precisely the issue of protecting the
hash algorithm used in the signature operation in those cases where it was
not completely obvious (i.e DSA which only permitted one signature
algorithm) or it was not included in the cryptographic block (RSA v1.5).  

Jim

> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2012 12:59 PM
> To: Jim Schaad
> Cc: 'Russ Housley'; [email-masked]; [email-masked]
> Doesn't this seem to argue against the need to protect parameters, since
the
> security of RSASSA-PSS is tightly related to the RSA problem itself?
> 
> 
> > I would also note that when PKCS#7 was designed, the hash algorithm
> > was always protected independent the presence of signed attributes.
> > Either the hash algorithm was in the signed attributes or it was in the
RSA
> signature
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Russ Housley
> >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the
> >>> content
> >> type is effectively always "id-data".
> >>