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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Apr 2013 23:25:44 -0700

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

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Thu, 4 Apr 2013 14:47:41 +0000

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.
- 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.

- 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.

- 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.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jim Schaad
> Sent: Thursday, April 04, 2013 2:26 AM
> To: [email-masked]
> Subject: [Cfrg] What Algorithm information needs to be authenticated?
> 
> Request for Information
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 10:03:13 -0700

Kevin,

> From: Igoe, Kevin M. [mailto:[email-masked]]
> Sent: Thursday, April 04, 2013 7:48 AM
> To: 'Jim Schaad'; [email-masked]
> Subject: RE: [Cfrg] What Algorithm information needs to be authenticated?
> 
become
> real.
> 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.
> 

I agree that both of the previous issues should be addressed as security
considerations.  I can check but I already believe they are.

>   the risk level is (in most applications) much lower than with digital

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.

>   if legal culpability might become an issue), a true signature should be

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.

>   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

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Jim Schaad
> > 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.
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> > 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
> > 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
> >
> >

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Thu, 4 Apr 2013 17:14:28 +0000

Jim Schaad wrote:
> > - With MACs, since the integrity keys are shorter lived than the
> signing
> keys,

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.

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Thursday, April 04, 2013 1:03 PM
> To: Igoe, Kevin M.; [email-masked]
> and
> given
> algorithm
> parameters
> >   While outside the scope of JOSE, I believe this should be called
> out in
> the
> > - With MACs, since the integrity keys are shorter lived than the
> signing
> keys,
> >   k.  Thankfully NIST has thought long and hard about these issues.
> We
> need to
> > > separated with a weight on the theoretical attacks for the
> potential
> > > to become real.
> > >

---

From: Richard Barnes <[email-masked]>
Date: Thu, 4 Apr 2013 15:01:30 -0400

> cryptographic "hygene" is harder than getting my kids to brush their

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 17:46:43 -0400

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

To make sure CFRG has the proper context: That last sentence should be read as my opinion, not something binding on the JOSE working group.  

What is clear here is that one of the two following things has to happen:
1. Extend the JOSE format to support short-lived MAC keys (like CMS AuthenticatedData), or
2. Add security considerations to the JOSE documents requiring that JOSE-using applications ensure that MAC keys are short-lived.

It is my strong personal opinion that (1) is the correct answer, since (2) relies on unspecified mechanisms to ensure the security of the protocol.  However, in the past, the JOSE WG has had a consensus call before on (1) and decided against it, so (2) seems the more likely course.

--Richard

---

From: Ben Laurie <[email-masked]>
Date: Fri, 5 Apr 2013 22:56:22 +0100

> such as the IV in case a new AEAD algorithm does not directly protect that

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

---

From: Ben Laurie <[email-masked]>
Date: Fri, 5 Apr 2013 23:02:34 +0100

On 5 April 2013 23:00, Mike Jones <[email-masked]> wrote:
> Indeed, "all parameters should be protected" is the security posture taken in the current JOSE specifications.  Some want to change that.

OK. Why?

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 22:00:28 +0000

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

				-- Mike

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

On 4 April 2013 07:25, Jim Schaad <[email-masked]> wrote:
> to protect the various header information in an encrypted or signed message.
> attack on a single algorithm as I don't know if this has ever been studied.
>
> the signature operation to prevent real and theoretical attacks on JOSE signed
> 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"?

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 18:17:10 -0400

On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <[email-masked]> wrote:

> > Indeed, "all parameters should be protected" is the security posture
> taken in the current JOSE specifications.  Some want to change that.
>
> OK. Why?
>
>
Is that "Why are all parameters protected?" or "Why do some people want to
change that"?

--Richard

---

From: Ben Laurie <[email-masked]>
Date: Fri, 5 Apr 2013 23:18:07 +0100

> Is that "Why are all parameters protected?" or "Why do some people want to

The latter.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 18:32:10 -0400

> > Is that "Why are all parameters protected?" or "Why do some people want

I'll summarize in the following points:
1. The protection reduces the utility of the protocol.
2. The protection increases the complexity of the protocol.
3. The protection does not appear to actually prevent any attacks.
4. The protection introduces some new vulnerabilities (or at least
unacceptable trade-offs).
5. If you still want it, despite the above, it is trivial to implement over
the top.

(In light of point (3), the word "protection" should be read with
appropriate irony herinafter.)

Further details:

1. The protection reduces the utility of the protocol.

The protection of security parameters in JWE is accomplished by placing the
parameters in the AAD input to an AEAD algorithm (i.e., the data that are
authenticated, but not encrypted).  This means that the AAD field cannot be
used for any other purpose, ruling out any use case that requires this
capability.

2. The protection increases the complexity of the protocol.

If the protection were not present, then the recipient of an object could
simply read the parameters and use them to process the object.  However,
because the processing requires the serialized parameters as input, one
needs to keep around both the serialized and the parsed forms of the
parameters.  The need for the serialization of the parameters to be fixed
also prevents a natural JSON representation (since JSON is not canonical).

3. The protection does not appear to actually prevent any attacks.

Russ summarized this nicely on CFRG a few days ago:
<http://www.ietf.org/mail-archive/web/cfrg/current/msg03376.html>

4. The protection introduces some new vulnerabilities.

Efficiently encrypting an object for multiple recipients is a major use
case for JOSE.  With the parameters as AAD, this causes re-use of nonces in
GCM, which is clearly a problem.  Avoiding nonce re-use removes all
efficiency gains for the multiple recipient case.
<http://www.ietf.org/mail-archive/web/cfrg/current/msg03373.html>

5. If you still want it, despite the above, it is trivial to implement over
the top.

Just put a hash of the parameters within the authenticated content.  (I
would even be happy to define a standard mechanism for doing this.)

Hope that helps,
--Richard

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Apr 2013 19:56:31 -0300

I took Russe's as being confirmation of why he believes CMS doesn't need to protect it's recipient-info.

One thing to note is that the JWE version of recipient info is extensible by WG decision.  
Some of those extensions are security related and benefit from integrity protection.

On point 3,  while on the face of it integrity protecting the algorithm information doesn't stop the key wrap alg from being changed before it is used, with proper care all such tampering with the JWE can be reported as a single failure.   Continuing with decrypting the body and generating a integrity error at the end has some benefit in discouraging timing attacks.

One of the reasons we decided to integrity protect the header was based on Ben's original advice.  We may not know all of the possible future attacks, so better to be safe.

I agree that Richard has a point with GCM and some possible serializations.  Personally I would rather find a way to do it with a single GCM tag and keep the integrity protection.

On point 1 I think that is a bit overplayed.  JWE doesn't specify how to serialize an additional AAD , and if you needed to it could be added as an element to the envelope.
I think that can be dealt with.

The bottom line is we are supporting only AEAD algorithms.    Putting the envelope in the AAD to integrity protect it is not a huge complication.

John B.

On 2013-04-05, at 7:32 PM, Richard Barnes <[email-masked]> wrote:

> 4. The protection introduces some new vulnerabilities (or at least unacceptable trade-offs).
> 5. If you still want it, despite the above, it is trivial to implement over the top.
> 
> (In light of point (3), the word "protection" should be read with appropriate irony herinafter.)
> 
> Further details:
> 
> The protection of security parameters in JWE is accomplished by placing the parameters in the AAD input to an AEAD algorithm (i.e., the data that are authenticated, but not encrypted).  This means that the AAD field cannot be used for any other purpose, ruling out any use case that requires this capability.
> 
> 
> If the protection were not present, then the recipient of an object could simply read the parameters and use them to process the object.  However, because the processing requires the serialized parameters as input, one needs to keep around both the serialized and the parsed forms of the parameters.  The need for the serialization of the parameters to be fixed also prevents a natural JSON representation (since JSON is not canonical).
> 
> 
> Efficiently encrypting an object for multiple recipients is a major use case for JOSE.  With the parameters as AAD, this causes re-use of nonces in GCM, which is clearly a problem.  Avoiding nonce re-use removes all efficiency gains for the multiple recipient case.
> 5. If you still want it, despite the above, it is trivial to implement over the top.
> 
> Just put a hash of the parameters within the authenticated content.  (I would even be happy to define a standard mechanism for doing this.)
> 
> 
> Hope that helps,
> --Richard
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 19:03:01 -0400

> Some of those extensions are security related and benefit from integrity

Then you should put them in an integrity protected object.

CMS EnvelopedData does have extensible attributes.  In fact, they are
explicitly called "unprotectedAttrs"!

EnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

So extensibility is not a difference here.

> On point 3,  while on the face of it integrity protecting the algorithm
> information doesn't stop the key wrap alg from being changed before it is
> used, with proper care all such tampering with the JWE can be reported as a
> single failure.   Continuing with decrypting the body and generating a
> integrity error at the end has some benefit in discouraging timing attacks.
>

That is true whether the parameters / header are integrity protected or
not.

> One of the reasons we decided to integrity protect the header was based on
> Ben's original advice.  We may not know all of the possible future attacks,
> so better to be safe.
>

The point of Russ's message is that there's not actually any additional
safety here.

> I agree that Richard has a point with GCM and some possible
> serializations.  Personally I would rather find a way to do it with a
> single GCM tag and keep the integrity protection.
>

If you want to achieve that objective, then you need to at least remove
per-recipient parameters from the integrity protection.

> On point 1 I think that is a bit overplayed.  JWE doesn't specify how to
> serialize an additional AAD , and if you needed to it could be added as an
> element to the envelope.
> The bottom line is we are supporting only AEAD algorithms.    Putting the
> envelope in the AAD to integrity protect it is not a huge complication.
>

But the fact that there is no clear benefit to it means that it should at
most be optional.

--Richard

> The protection of security parameters in JWE is accomplished by placing
> the parameters in the AAD input to an AEAD algorithm (i.e., the data that
> are authenticated, but not encrypted).  This means that the AAD field
> cannot be used for any other purpose, ruling out any use case that requires
> this capability.
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Apr 2013 20:20:11 -0300

Richard,

I think it was Jim that pointed out RFC 6211 "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute" adds a new CMS parameter to protect the algorithm identifier in CMS.    

The existence of RFC 6211 makes me feel lees alone in my opinion on the value of integrity protecting recipient info.

There are downsides for multiple recipients.  I would rather work through that than throw out integrity protectin for recipiant info. 

I may be in the minority on that we will have to see.   

I hope that the Cfrg can provide some wisdom on this as the two of us could argue this for a long time without getting to conclusion as it is hard to absolutely prove either side of the argument. 

Regards
John B.

On 2013-04-05, at 8:03 PM, Richard Barnes <[email-masked]> wrote:

> CMS EnvelopedData does have extensible attributes.  In fact, they are explicitly called "unprotectedAttrs"!
> 
> That is true whether the parameters / header are integrity protected or not.  
> 
>  
> The point of Russ's message is that there's not actually any additional safety here.
> 
>  
> If you want to achieve that objective, then you need to at least remove per-recipient parameters from the integrity protection. 
> 
>  
> But the fact that there is no clear benefit to it means that it should at most be optional.
> 
> --Richard
> 
> 
>  
> 
> John B.
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 22:01:36 -0400

Fair enough point that there are some signature schemes that are vulnerable
to the attacks laid out in RFC 6211.  I don't really see that as a reason
to levy a requirement on other signature schemes, and on encrypted objects.
 It seems sufficient to have an optional protection that can be enabled for
vulnerable algorithms.

But I also agree with John that other peoples' perspectives are more
important than ours, so I'll shut up now :)

--Richard

On Friday, April 5, 2013, John Bradley wrote:

> Richard,
>
> I think it was Jim that pointed out RFC 6211 "Cryptographic Message
> Syntax (CMS) Algorithm Identifier Protection Attribute" adds a new CMS
> parameter to protect the algorithm identifier in CMS.
>
> The existence of RFC 6211 makes me feel lees alone in my opinion on the
> value of integrity protecting recipient info.
>
> There are downsides for multiple recipients.  I would rather work through
> that than throw out integrity protectin for recipiant info.
>
> I hope that the Cfrg can provide some wisdom on this as the two of us
> could argue this for a long time without getting to conclusion as it is
> hard to absolutely prove either side of the argument.
>
> Regards
> John B.
>
>
> > On Fri, Apr 5, 2013 at 6:02 PM, Ben Laurie <[email-masked]>
>
>

---

From: Ben Laurie <[email-masked]>
Date: Sat, 6 Apr 2013 11:55:06 +0100

> used for any other purpose, ruling out any use case that requires this

That seems easy enough to fix, define the AAD input to be len(JWE
stuff) + JWE stuff + other stuff.

> also prevents a natural JSON representation (since JSON is not canonical).

Traditionally this has been fixed by not attempting to canonicalise or
serialise the JSON but instead to b64 encode the JSON, however it
happens to come out, and using that as the input for authentication.

> <http://www.ietf.org/mail-archive/web/cfrg/current/msg03376.html>

That is hardly an exhaustive analysis.

> Efficiently encrypting an object for multiple recipients is a major use case
> for JOSE.  With the parameters as AAD, this causes re-use of nonces in GCM,
> which is clearly a problem.  Avoiding nonce re-use removes all efficiency
> gains for the multiple recipient case.

So what you mean is that integrity reduces efficiency (clearly you
should not choose to compromise security, if security is your goal).

I don't know enough about the protocols to propose a solution but
would note that a common solution is to have the per-recipient part
encrypt a key to the common part (which is the same key for everyone,
of course), like multi-recipient PGP. Dunno if that helps in this
case.

> would even be happy to define a standard mechanism for doing this.)

If you want to get integrity by some mechanism other than AAD that's fine by me.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 6 Apr 2013 11:56:58 +0100

> Ben's original advice.  We may not know all of the possible future attacks,

Quite. A recurring pattern we see is that crypto mechanisms get pared
down to the bare minimum. Which later turns out to be a little less
then the minimum. Its time we resisted that temptation and started
over-specifying crypto.

> I agree that Richard has a point with GCM and some possible serializations.
> Personally I would rather find a way to do it with a single GCM tag and keep
> the integrity protection.
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Apr 2013 16:19:03 -0400

On Sat, Apr 6, 2013 at 6:55 AM, Ben Laurie <[email-masked]> wrote:

> >> > Is that "Why are all parameters protected?" or "Why do some people
> want
> >> > to
> >> > change that"?
> >>
> >> The latter.
> >
> >

Assuming you don't care about being ciphertext-compatible with anything
else.  Not sure if that's a requirement, but it seems like it could be a
handy feature.

> happens to come out, and using that as the input for authentication.

What you describe is precisely what JOSE does, and what creates the
complexity.  The parameters are Base64 encoded before inclusion in the AAD.
 The complexity is on the receiver end, when I have to decode the
base64-encoded parameters, but also keep the encoded version around for
inclusion as AAD.

> That is hardly an exhaustive analysis.

That's not really a rebuttal.  The point is that the only reason to add
complexity is to achieve some security benefit.

The only benefit that has been proposed so far is John's observation about
RFC 6211, which makes more sense as an *optional* feature (see point 5),
since most algorithms have no need of it.

> case

Let me expand a little on how integrity reduces efficiency.  In particular,
how integrity on per-recipient parameters reduces efficiency.

A JOSE encrypted object (in the current format) comprises a logical 5-tuple
(parameters, wrapped-key, iv, ciphertext, mac), where the integrity check
("mac") covers the first three entries.  If you have multiple recipients,
then then obviously, the wrapped-key values are going to be different
per-recipient.  (That of course means the integrity check values ("mac")
will be different per recipient.)

However, GCM forbids the re-use of a key/IV pair for two different
plaintexts.  So it's not OK to have:
   (ciphertext_1, mac_1) = gcm(key, iv, plaintext, parameters ||
wrapped-key_1 || iv)
   (ciphertext_2, mac_2) = gcm(key, iv, plaintext, parameters ||
wrapped-key_2 || iv)
That means that the IV field has to be different per recipient as well.
 Finally, the parameters field includes per-recipient parameters, so it
will also be different per recipient.

In an ideal world, the only difference between two encrypted objects for
different recipients would be in the wrapped keys (as is the case for CMS,
even with RFC 6211).  But to support GCM in the current JOSE specs, none of
the five parts of the object can be the same.  This removes all
optimization from the multiple-recipient case.

> If you want to get integrity by some mechanism other than AAD that's fine

Certainly, you could have parameter integrity just by wrapping an encrypted
object in a signed/MACed object.

I would be happy enough if the current mechanism were made optional.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Apr 2013 16:26:13 -0400

On Sat, Apr 6, 2013 at 6:56 AM, Ben Laurie <[email-masked]> wrote:

> > I took Russe's as being confirmation of why he believes CMS doesn't need
> to
> > protect it's recipient-info.
> >
> > One thing to note is that the JWE version of recipient info is
> extensible by
> > WG decision.

So it's better to do DES twice than just once, right [1]?  Or double-ROT13?
 :)

Seriously, if we're going to design cryptographic security mechanisms, we
should know what problem we're trying to solve.  It is easy in this space
to do more work for no benefit.

--Richard

[1] <http://en.wikipedia.org/wiki/Meet_in_the_middle_attack>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 10 Apr 2013 10:54:09 +0100

> So it's better to do DES twice than just once, right [1]?  Or double-ROT13?

It's not worse :-)

And, in fact, DES-2 actually _is_ better than DES-1.

> should know what problem we're trying to solve.  It is easy in this space to
> do more work for no benefit.

I don't disagree with that. So, the problem signing parameters is
designed to solve is: algorithm becomes weak, algorithm specifier is
not authenticated, manipulation of specifier is therefore trivial,
authentication/content of the message is thus more easily faked.

Now, you're going to say that if the specifier is authenticated by the
broken algorithm, then it isn't authenticated anyway - and my response
is that the more stuff the attacker has to get to come out right, the
harder his job is.

Without knowing what the specific break is, its hard to say whether
this is going to matter in practice or not. But ... it seems unlikely
to make matters worse.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 10 Apr 2013 07:57:16 -0400

This question becomes: how much extra work do we have to do (including inconvenience and pitfalls we're creating for the implementers) to force the attacker walk an extra step, and how much (if at all) those extra steps matter (e.g., 2^56 vs 2*2^56?).

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Ben Laurie [mailto:[email-masked]]
Sent: Wednesday, April 10, 2013 05:54 AM
To: Richard Barnes <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Cfrg] What Algorithm information needs to be authenticated?

It's not worse :-)