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

["Jim Schaad" <[e-mail]>]

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