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

[Richard Barnes <[e-mail]>]

On Apr 4, 2013, at 1:14 PM, "Igoe, Kevin M." <[e-mail]> wrote:

> Jim Schaad wrote:
>>> - With MACs, since the integrity keys are shorter lived than the
>> signing
>> keys,
>>>  the risk level is (in most applications) much lower than with
>> digital
>>>  signatures.
>> 
>> I wish this was a true statement.  I have seen a number of
>> circumstances
>> where MAC keys are in long lived situations on the order of years.
>> Places
>> such as routers, RADIUS servers and so forth.  Thus while we can hope
>> they
>> are shorter lived I don't believe that we can make that as an
>> assumption.
>> 
> 
> Sigh! Sadly, ! expect you are right.  Getting people to have proper 
> cryptographic "hygene" is harder than getting my kids to brush their
> teeth every night.

The current JOSE specs, however, encourage bad habits: Unlike CMS, they don't provide a mechanism for using ephemeral MAC keys.

So that is one helpful piece of feedback.  We need to add better ways to manage MAC keys.

--Richard




> 
>> -----Original Message-----
>> From: Jim Schaad [mailto:[e-mail]]
>> Sent: Thursday, April 04, 2013 1:03 PM
>> To: Igoe, Kevin M.; [e-mail]
>> Subject: RE: [Cfrg] What Algorithm information needs to be
>> authenticated?
>> 
>> Kevin,
>> 
>>> -----Original Message-----
>>> From: Igoe, Kevin M. [mailto:[e-mail]]
>>> Sent: Thursday, April 04, 2013 7:48 AM
>>> To: 'Jim Schaad'; [e-mail]
>>> Subject: RE: [Cfrg] What Algorithm information needs to be
>> authenticated?
>>> 
>>> OK CFRG, Jim has given us 4 concrete issues to address.
>>> 
>>> 
>>> 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.
>>> 
>>> - A residual risk common to all of these is proper storage of secret
>> keys.
>>>  While outside the scope of JOSE, I believe this should be called
>> out in
>> the
>>>  security section as an issue implementers must address.)
>>> - Proper protection of the secret signing keys is a very real issue.
>> 
>> I agree that both of the previous issues should be addressed as
>> security
>> considerations.  I can check but I already believe they are.
>> 
>>> - With MACs, since the integrity keys are shorter lived than the
>> signing
>> keys,
>>>  the risk level is (in most applications) much lower than with
>> digital
>>>  signatures.
>> 
>> I wish this was a true statement.  I have seen a number of
>> circumstances
>> where MAC keys are in long lived situations on the order of years.
>> Places
>> such as routers, RADIUS servers and so forth.  Thus while we can hope
>> they
>> are shorter lived I don't believe that we can make that as an
>> assumption.
>> 
>>> 
>>> - ECDSA depends upon a random input k provided by the signer. This
>> input
>>>  should be uniformly distributed in the range [1, q], where q is
>>>  the size of the cryptographic subgroup of the curve (a prime).
>> NIST has
>>>  good guidance on this.  One of their DRBGs makes a good tool for
>> forming
>>>  k.  Thankfully NIST has thought long and hard about these issues.
>> We
>> need to
>>>  point folks at the proper NIST special pubs. Additional non-NIST
>> references
>>>  would be a very welcome!
>>> 
>>> - MACs don't provide non-repudiation since more than one person has
>> the
>>>  integrity key.  If non-repudiation is required (typically only
>> needed
>>>  if legal culpability might become an issue), a true signature
>> should be
>>>  used.
>> 
>> I prefer the term data-origin rather than non-repudiation since I know
>> what
>> that the former means but don't know what the latter means as a
>> technical
>> term.  This term has been argued about for the last 15 years on the
>> PKIX
>> mailing list and I don't want to get into that here.
>> 
>>> 
>>> - OK folks, does anyone have an argument as to why authentication of
>> the
>>>  AEAD IVs is required to address a concrete security issue?  I've
>> been
>>>  mulling this over & haven't come up with one yet. Keep in mind that
>> one
>>>  of the use cases for JOSE is the W3C web cryptography API, so there
>>>  are likely to use this in the future to build JOSE based
>> applications
>>>  beyond what we are currently envisioning.
>> 
>> Are you talking about inside of the algorithm or outside of the
>> algorithm
>> for doing the authentication?  In the case of the CBC/HMAC AEAD
>> algorithm,
>> as the authentication is computed on the encrypted text you cannot know
>> if
>> the unencrypted text is the correct text without knowing that the IV is
>> also
>> correct.   You end up with about a 1 in 256 chance of decrypting the
>> message
>> and getting the correct padding with the wrong IV and then assuming
>> that the
>> resulting plain text is what was sent when it isn't.
>> 
>> Jim
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>>>> Of Jim Schaad
>>>> Sent: Thursday, April 04, 2013 2:26 AM
>>>> To: [e-mail]
>>>> Subject: [Cfrg] What Algorithm information needs to be
>> authenticated?
>>>> 
>>>> 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.
>>>> 
>>>> 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
>>>> [e-mail]
>>>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg