Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jun 2012 23:07:13 +0000

Two years ago when the developer community needing a JSON-friendly token format was designing the JSON Web Token (JWT), we explicitly asked security experts whether the header parameters should be integrity protected or not.  Among them, Ben Laurie was one of the voices saying that securing them was the right thing to do.

He argued that if the parameters can be protected in a practical manner, then they should.  Doing so provides an additional hurdle that attackers would have to surmount.  For example, if they can try to substitute a weaker authentication scheme, then they must figure out how to make it authenticate correctly despite some plaintext they can't control - the header parameters.

Ben also took the position that paring security protocols down to the least you can get away with, given attacks you can think of, is not a good design principle.  If there is not a strong argument against including a feature that may make it harder for attackers, then that feature should be included.

I agree with him.

The decision to provide integrity protection for the headers is documented in the session notes at http://self-issued.info/?p=361, which said:

*  What to sign (envelope.payload or just payload)?

Given that the envelope is extensible and therefore may contain security-sensitive information, we reached a consensus (with input from Ben Laurie<http://www.links.org/> via IM) that the combination envelope.payload must be signed.

I believe that logic is as sound today as it was then.

For all these reasons, I therefore personally stand by the community's decision to provide integrity protection for the headers.

                                                            Best wishes,
                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, June 20, 2012 3:57 PM
To: Richard L.Barnes
Cc: [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

Hi Richard,

While for PKCS 1.5 the hash algorithm is baked into the padding and not susceptible to modification with ECDH or RSA-PSS it is not.

There are possible hash truncation attacks by shortening SHA256 to SHA224 as an example (I know we preclude truncated hashes at the moment).

The bad feeling I get around this is that if there is a scenario where the attacker controls the plaintext to be signed and there is no signer controlled text contributed there are potential bad things that could happen down the road.

This bit us with x509 certs not that long ago (yes with MD5 admittedly) where the attacker could use a certificate extension to include extra data and cause a pre collided hash to be generated.

Having part of the signed data outside the control of an attacker is a good thing.  (having a nonce or message ID in the envelope is possible though not yet required in JWS.)

I am still of the opinion that putting the base64 encoded envelope inside the hash calculation is a valid way to allow additional attributes.

Another structure to hold the attributes adds more complexity,  as would saying that they need to be inside the signed object.

I think part of this is that as one of the openID Connect authors I look at this as a necessary security token format, for OAuth and Connect.

For that simple processing with one signature is a high priority for adoption.

>From a general signing/encrypting of documents point of view you legitimately have different priorities.

I know it is hard to prove a negative but It is also going to be difficult for me to go back to security people at google Facebook and other places and explain how not integrity protecting the header could be better than integrity protecting it.

It seems that I would be reduced to arguing that this is no worse than CMS and that hasn't been proven insecure yet.

Allowing a possible attacker to control the hash output, and not integrity protecting the additional data, seems like something I am bound to regret in the future.

Regards

John B.

On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote:

> Hey John,

> Interesting points, but I don't think they actually apply here.

> With regard to downgrade attacks:

> The attack that RFC 5752 is concerned with is when an attacker strips signatures from a signed message, so that the only ones left are ones he can tamper with.  So the integrity protection here is "horizontal"; it goes across signatures.  The integrity protection in JWS/JWE is "vertical" -- it only protects one signer's parameters -- so it is, so to speak, orthogonal.

> With regard to "brown bag" attacks:

> The root of this attack is ambiguity about what content is *signed*

> vs. what content is *used*.  If an application doesn't verify that

> it's actually using the stuff that's signed, then it can be tricked

> into accepting something unsigned. (Cf.

> <http://en.wikipedia.org/wiki/Confused_Deputy>)

> However, I don't think any of the current proposals have that problem.  In JWE/JWS, the signed content is right there between the dots, and in JSMS, it's in the "content" element.  The current JSMS draft does allow detached signatures, but with a "voids your warranty" sticker on it.

> In any case, these attacks have nothing to do with whether the cryptographic parameters are integrity-protected with the content.  The example attacks in the IBM still work regardless -- the whole point of the attack is that the cryptographic processing is the same, only the (non-crypto) matching of content is flawed.

> With regard to "arbitrary attributes":

> We can have that here, too, but you need canonicalization.  And base64-encoding is not not canonicalization -- it just waves its hands over the question of equivalence.  In my opinion, we should keep the cryptographic object simple by disallowing attributes, and push the attributes you would sign inside of the thing being signed.  If people really do want attributes, it doesn't seem to me like JSON canonicalization is very hard.  I can do it in 19 lines of python:

> <http://pastebin.com/ptUfn0c3>

> With regard too "meta-data in the body":

> It seems to me like if we're trying to define a general format for applying security protections, then we ought to keep out things that aren't strictly security relevant.  Those things can go in application-specific content types (e.g., SAML) without polluting the general purpose header.

> With regard to "defense in depth" and selling this to government agencies:

> CMS, via S/MIME, is in broad use across multiple federal agencies and large enterprises.  JSMS is essentially a profile of CMS (see Section 7), and has the same security properties.

> Cheers,

> --Richard

> On Jun 19, 2012, at 5:10 PM, John Bradley wrote:

>> Hi Richard,

>> Originally we only integrity protected the header for signing.  We added the integrity protection to encryption as part of AEAD, as encryption can also be used for sender verification.

>> I understand the argument that it makes things simpler if we don't integrity protect the header information.

>> However xmldsig,  provides integrity over those elements to prevent possible downgrade attacks by manipulating the algorithms.

>> CMS may not typically provide that integrity protection but I think Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks.

>> Given they are on this list they can speak to their view on integrity over the crypto parameters.

>> I also recall when working on InfoCards there was a Monte Carlo/Brown Bag attack that needs to be considered if we move to something more like a detached signature.

>> The other design consideration is that we wanted to be able to sign arbitrary byte strings not just JSON.   You could sign XML if you wanted.

>> That prevented us from including meta-data in the body as we didn't want to touch it.   That left us with the header to include additional elements in.

>> Not integrity protecting those elements as well would be a problem.

>> I am not a CMS expert but I believe it allows for signing of arbitrary attributes not unlike the current JOSE spec.

>> Especially for something that will be used with JWT security tokens I will have a hard time making the argument to NIST and others that need to approve this format that not integrity protecting the header parameters is appropriate defence in depth, for something that might be replacing signed SAML assertions in some applications.

>> I do understand how not integrity protecting the header will make some things easier, however I can't agree that the benefit outweighs the disadvantages.

>> Regards

>> John B.

>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote:

>>> Hey Mike,

>>> Thanks for having some back-and-forth with me on this.  I think this is a good discussion to have right now.  I would like to discuss some high-level points, and then I'll respond inline to your precise points.

>>> tl;dr: In order to meet its deliverables, the WG needs to define JSON-based formats for integrity and confidentiality protections.  JWE and JWS don't fit that requirement, so we should re-consider their adoption and call for new candidates.

>>> Major points:

>>> 1. JOSE is JSON

>>> 2. JSON does not imply canonicalization 3. Compactness and

>>> URL-safeness are still OK, as derivatives

>>> Part 1: JOSE is JSON

>>> The JOSE WG charter calls out four deliverables, three of which are explicitly required to be JSON:

>>> -- "JSON-structured integrity protection"

>>> -- "JSON-structured encryption"

>>> -- "public keys as JSON-structured objects"

>>> (The fourth is just a list of algorithms, which should be JSON as

>>> well, just as RFC 3370 is ASN.1.)

>>> In light of these requirements, JWE and JWS are clearly not suitable

>>> candidates to fulfill the working group's milestones.  (At least in

>>> their current form.)  So ISTM that we need to step back and

>>> re-evaluate alternatives for the three above milestones, especially

>>> the first two.  (JWK is not as far off.)

>>> As JSON-based mechanisms, though, the "JSON serialization" drafts are pretty half-hearted.  Because JWS and JWE include the cryptographic parameters within the integrity protection, they have to have the headers included as base64-encoded strings.  That obviously adds a lot of complexity to encoding and decoding -- for example, you have to keep the encoded header around even after you've decoded it! -- and just plain more octets.  The support for multiple recipients and multiple signatures is both unweildy (matching up parallel indices for headers and signatures) and inefficient (multiple integrity check values in encrypted objects).

>>> By contrast, JSMS takes advantage of the cryptographic wisdom that went into CMS, while making the syntax pure JSON and as simple as possible.  Multiple signatures and multiple recipients are supported with absolute minimum overhead.  So I think it's worth consideration by the working group.

>>> Part 2: JSON !=> canonicalization

>>> I would like to dispel the myth that a JSON-based format requires

>>> canonicalization.  In JWE/JWS, the JSON header requires

>>> "canonicalization" (via base64url encoding) because it's included

>>> within the integrity protection.  I'm not aware of any reason for

>>> including the cryptographic parameters in the integrity check,

>>> instead of only integrity-protecting the content itself.  Indeed, if

>>> there were an attack based on non-integrity-protected cryptographic

>>> parameters, it would be a pretty big deal, since neither CMS nor IKE

>>> nor provides this protection.  (TLS does provide a signature over

>>> the algorithms, but only as a way to bind the public key to the

>>> session.)

>>> Indeed CMS doesn't require canonicalization at all, except for attributes that are included in the protected content (signedAttrs / authenticatedAttrs), which need to be DER-encoded.  In JSMS, we don't allow those parameters, so there is no need for canonicalization at all.  All the "canonicalization" that's needed is to base64url-encode the protected content.  In that regard, JSMS is even simpler than JWE/JWS.

>>> Part 3: Compactness and URL-safeness are still OK, as derivatives

>>> I have absolutely no objection to defining a compact, URL-safe format.  Indeed, I did so in the JSMS draft, in Section 5.  Encoding the example from Section 3.1 of the JWS spec, we get the following JSMS object:

>>> {

>>>   "v":1,

>>>   "t":"au",

>>>   "a":"hs256",

>>>   "c":"eyJpc3MiOiJqb2...0cnVlfQ",

>>>   "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",

>>>   "ki":"rSIilRk8Ego"

>>> }

>>> If we remove the decorative spaces and base64url-encode, we only use

>>> 88 octets more than JWS (267 vs. 179).  If we take this a step

>>> further and define an explicit compact format for AuthenticatedData,

>>> we can emulate JWS by moving the content and MAC fields outside and

>>> dot-combining.  That avoids double-base64url-encoding, and only

>>> takes up 11 more octets than a JWS (190 vs 179).  (I've put the code

>>> to generate these in the Github project linked earlier.)

>>> So it's fine to have a compact, URL-safe format for an objective, but it makes *much* more sense to derive that from a full-size, usable, JSON format than the other way around.

>>> Responses to specific points inline below.

>>>> Fair enough.  I'll briefly respond to each in turn.  Before doing so, I'll say that I'm writing in the spirit of trying to increase mutual understanding and consensus, rather than taking the point of view that the status quo is the only reasonable outcome.

>>>> -- Not being JSON

>>>> This was by design, so that the results are URL-safe.  This is required, for instance, for them to be used as OAuth Bearer Tokens.  At the request of the working group, closely related pure-JSON drafts were also published.  See:

>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri

>>>> alization-01 and

>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser

>>>> ialization-01

>>>> Use them if you prefer if they better suit your use cases.  They could be adopted as working group documents, if there's interest.

>>> See above.  These are super-clunky, and the need to be the main focus of the WG, not an afterthought.

>>>> -- Not supporting multiple recipients

>>>> The JSON serialization drafts above do, again, in response to use cases presented by the working group.

>>> See above.  Because of the unnecessary inclusion of the header in the integrity check, this is far less efficient than it should be.

>>>> -- Lacking clear distinctions between signing and MAC

>>>> Functionally, these are very similar operations, at least from an implementation perspective, so it's not clear that making a clear distinction would help either developers or adoption in any practical way.  They achieve overlapping, but admittedly sometimes different goals.  I believe that developers can be trusted to use the algorithms that achieve their applications' goals without making a hard distinction between the two.  But I'd be interested in hearing your thoughts on why you believe a brighter-line distinction might be useful or necessary.

>>> It's important if you want to do MACs with anything other than pre-shared keys.  If you want to do anything more advanced, you need to have wrapped keys, in which case an object with a MAC starts to look a lot more like a JWE than a JWS.

>>>> -- Lacking clear processing instructions for different key

>>>> establishment modalities

>>>> This seems like an area where the existing drafts could be refined to add descriptions for additional establishment modalities, possibly based upon your ideas and descriptions, should the working group decide to do so.  What additional modalities do you have use cases for that you believe are not achievable or straightforward with the existing drafts?  The existing modalities supported are largely those that existing developers had told us they needed and draw both from the precursor draft-jones-json-web-* documents and draft-rescorla-jsms.

>>>> Bear in mind that the balance that the current drafts try to strike is keeping the Mandatory to Implement (MTI) feature footprint small enough that developers, including Web developers, are likely to adopt the specs, while still providing enough functionality to make them generally useful.  As in any balance, it's often possible to shift things a bit and still maintain the balance, but I'd like people to keep the ubiquitous adoption goal front-and-center when proposing additional functionality.

>>>> Ubiquitous deployment and usefulness trump theoretical

>>>> completeness.  (Just look at XMLDSIG and XMLENC to understand

>>>> that!)

>>> I agree that we need to find a reasonable MTI.  The current JSMS draft doesn't really specify which parts are MTI, beyond basic things like base64url encoding and ignoring unknown fields.

>>> My main concern is that JWS and JWE don't really tell me which fields need to be present for which use case.  If I'm putting a MAC on a JWS vs. a signature, do I need "jwk" or "jku" fields to be populated?  Whereas in JSMS, I think these things are much clearer due to the separation of the use cases (Signed/Authenticated/Encrypted) and the isolation of signatures and wrapped keys into sub-objects.

>>>> -- Lack of clear typing of objects

>>>> Most JSON documents aren't clearly typed; instead, developers and implementations understand from context what the meaning of each field is.  XML is clearly typed, but developers are voting with their feet by moving to JSON.

>>>> What practical advantages resulting from overlaying a typing infrastructure on JSON do you believe are worth the potential costs of doing so?  BTW, I'm not opposed to having a JSON schema description of the JOSE JSON data structures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll remark that this an informative tool, not a normative one.

>>> I actualy don't have a hugely urgent requirement here either.  It's something that others in the WG had requested, which is trivial to add in JSMS, but not in JWE/JWS -- again because of the unnecessary integrity protection of the header.

>>>> -- Lack of versioning for future extensibility

>>>> An optional version field could be added if the working group

>>>> desires, however the last time the working group discussed it, they

>>>> decided not to do so.  Rather, specs like this effectively become

>>>> "versioned" when revised in a way that new fields are added.  If

>>>> you understand the new fields, you support that new version.  (Note

>>>> that this is independent of whether there is a version number

>>>> field, which according to some participants in the previous

>>>> discussion, they regarded as therefore being redundant

>>>> information.)

>>>> I'm not religious about not having a version number field, but often "less is more".

>>> Indeed, I'm not religious either.  It just seems like a general good idea to state this directly as opposed to having parsers divine it based on which fields are present.  To quote RFC 5652:

>>> "

>>>  Each of the major data structures includes a version number as the

>>> first item in the data structure.  The version numbers are intended

>>> to avoid ASN.1 decode errors.  Some implementations do not check the

>>> version number prior to attempting a decode, and if a decode error

>>> occurs, then the version number is checked as part of the error

>>> handling routine.  This is a reasonable approach; it places error

>>> processing outside of the fast path.  This approach is also

>>> forgiving  when an incorrect version number is used by the sender.

>>> "

>>> Best,

>>> --Richard

>>>>                                                   Best wishes,

>>>>                                                   -- Mike

>>>> -----Original Message-----

>>>> From: Richard L. Barnes [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

>>>> Sent: Friday, June 15, 2012 3:00 PM

>>>> To: Mike Jones

>>>> Cc: [email-masked]<mailto:[email-masked]>

>>>> Subject: Re: [jose] Fwd: New Version Notification for

>>>> draft-barnes-jose-jsms-00.txt

>>>> Ok, so maybe I should have phrased my lead-in differently.  IMO, the current JW* specs are deficient in several ways, e.g.:

>>>> -- Not being JSON

>>>> -- Not supporting multiple recipients

>>>> -- Lacking clear distinctions between signing and MAC

>>>> -- Lacking clear processing instructions for different key

>>>> establishment modalities

>>>> -- Lack of clear typing of objects

>>>> -- Lack of versioning for future extensibility

>>>> Looking at the current specs, it didn't seem to me that it would be simple to adapt them to address these deficiencies.  So I just did a re-write.  If you think they can be addressed within the current framework, please explain.  I just found it simpler to start from whole cloth.

>>>> Cheers,

>>>> --Richard

>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:

>>>>> Hi Richard,

>>>>> If you're puzzled by specific design decisions in the JOSE documents, I encourage you to ask about them on the list.  The documents have significant history going back to mid-2010 when convergence discussions started among people with four different JSON signing & encryption proposals.  JWT and the current JOSE specs and implementations are the result.  I realize that not all the JOSE participants were part of those discussions from the beginning (although many were) and so teasing out the rationale for specific decisions might help people better understand the choices made, and hopefully thereby increase consensus behind the eventual working group choices.

>>>>> If the list that you're puzzled by is the bulleted list below, maybe we can start a discussion on that basis.

>>>>>                                                 Best wishes,

>>>>>                                                 -- Mike

>>>>> -----Original Message-----

>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On

>>>>> Behalf Of Richard L. Barnes

>>>>> Sent: Friday, June 15, 2012 2:08 PM

>>>>> To: [email-masked]<mailto:[email-masked]>

>>>>> Subject: [jose] Fwd: New Version Notification for

>>>>> draft-barnes-jose-jsms-00.txt

>>>>> Dear JOSE WG,

>>>>> Like Mr. Manger, once I finally got around to doing a thorough review of the JW* specs, I was kind of puzzled by some of the design decisions.  So I also went through and wrote an alternative format, this time taking a more of a cue from CMS.  A link to the document is below.

>>>>> Summary of differences:

>>>>> o  JSMS is pure JSON, whereas in JWE and JWS only the header

>>>>>   parameters are represented in JSON.

>>>>> o  JSMS allows for full algorithm agility in key agreement, while JWE

>>>>>   only allows ECDH-ES.

>>>>> o  JSMS supports multiple recipients for EncryptedData and

>>>>>   AuthenticatedData objects via the inclusion of multiple WrappedKey

>>>>>   objects.  Sending a JWE to multiple recipients requires re-

>>>>>   encryption of the entire object for each recipient.

>>>>> o  The signature and MAC functions of the JWS object are separated

>>>>>   into SignedData and AuthenticatedData JSMS objects.

>>>>> o  JSMS parameters are not integrity-protected, as they are in JWE

>>>>>   and JWS.

>>>>> o  The "typ" and "zip" parameters are not defined in JSMS, but could

>>>>>   be added without significant change.

>>>>> o  JSMS requires that recipients MUST ignore unknown header

>>>>>   parameters, in order to facilitate extensibility.

>>>>> I've also thrown together an initial JavaScript implementation (based on NodeJS for some python crypto glue), which is on github:

>>>>> <https://github.com/bifurcation/jsms>

>>>>> Comments are very welcome.

>>>>> Thanks,

>>>>> --Richard

>>>>> Begin forwarded message:

>>>>>> From: [email-masked]<mailto:[email-masked]>

>>>>>> Subject: New Version Notification for

>>>>>> draft-barnes-jose-jsms-00.txt

>>>>>> Date: June 15, 2012 4:56:09 PM EDT

>>>>>> To: [email-masked]<mailto:[email-masked]>

>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been

>>>>>> successfully submitted by Richard Barnes and posted to the IETF

>>>>>> repository.

>>>>>> Filename:             draft-barnes-jose-jsms

>>>>>> Revision:              00

>>>>>> Title:                     JavaScript Message Security Format

>>>>>> Creation date:    2012-06-15

>>>>>> WG ID:                  Individual Submission

>>>>>> Number of pages: 25

>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt

>>>>>> Status:          http://datatracker.ietf.org/doc/draft-barnes-jose-jsms

>>>>>> Htmlized:        http://tools.ietf.org/html/draft-barnes-jose-jsms-00

>>>>>> Abstract:

>>>>>> Many applications require the ability to send cryptographically

>>>>>> secured messages.  While the IETF has defined a number of formats

>>>>>> for such messages (e.g.  CMS) those formats use encodings which

>>>>>> are not easy to use in modern applications.  This document

>>>>>> describes the JavaScript Message Security format (JSMS), a new

>>>>>> cryptographic message format which is based on JavaScript Object

>>>>>> Notation (JSON) and thus is easy for many applications to generate and parse.

>>>>>> The IETF Secretariat

>>>>> _______________________________________________

>>>>> jose mailing list

>>>>> [email-masked]<mailto:[email-masked]>

>>>>> https://www.ietf.org/mailman/listinfo/jose

>>>>> _______________________________________________

>>>>> jose mailing list

>>>>> [email-masked]<mailto:[email-masked]>

>>>>> https://www.ietf.org/mailman/listinfo/jose

>>>> _______________________________________________

>>>> jose mailing list

>>>> [email-masked]<mailto:[email-masked]>

>>>> https://www.ietf.org/mailman/listinfo/jose

>>> _______________________________________________

>>> jose mailing list

>>> [email-masked]<mailto:[email-masked]>

>>> https://www.ietf.org/mailman/listinfo/jose

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jun 2012 00:11:20 +0900

Especially after the X.509 fiasco, I strongly believe that having integrity
check over the metadata is a good thing. It is such a little effort that
gives us much more protection down the road. In this sense, I fully agree
with Ben here. We should have integrity protection over the header.

Nat

On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones <[email-masked]>wrote:

>  Two years ago when the developer community needing a JSON-friendly token
> format was designing the JSON Web Token (JWT), we explicitly asked security
> experts whether the header parameters should be integrity protected or
> not.  Among them, Ben Laurie was one of the voices saying that securing
> them was the right thing to do.****
>
> ** **
>
> He argued that if the parameters can be protected in a practical manner,
> then they should.  Doing so provides an additional hurdle that attackers
> would have to surmount.  For example, if they can try to substitute a
> weaker authentication scheme, then they must figure out how to make it
> authenticate correctly despite some plaintext they can't control – the
> header parameters.****
>
> ** **
>
> Ben also took the position that paring security protocols down to the
> least you can get away with, given attacks you can think of, is not a good
> design principle.  If there is not a strong argument against including a
> feature that may make it harder for attackers, then that feature should be
> included.****
>
> ** **
>
> I agree with him.****
>
> ** **
>
> The decision to provide integrity protection for the headers is documented
> in the session notes at http://self-issued.info/?p=361, which said:****
>
> ** **
>
> *·**  What to sign (envelope.payload or just payload)?*****
>
> Given that the envelope is extensible and therefore may contain
> security-sensitive information, we reached a consensus (with input from Ben
> Laurie <http://www.links.org/> via IM) that the combination
> envelope.payload must be signed.****
>
> ** **
>
> I believe that logic is as sound today as it was then.****
>
> ** **
>
> For all these reasons, I therefore personally stand by the community’s
> decision to provide integrity protection for the headers.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> ** **
> Hi Richard,****
> ** **
> While for PKCS 1.5 the hash algorithm is baked into the padding and not
> susceptible to modification with ECDH or RSA-PSS it is not.****
>
> There are possible hash truncation attacks by shortening SHA256 to SHA224
> as an example (I know we preclude truncated hashes at the moment).****
>
> ** **
>
> The bad feeling I get around this is that if there is a scenario where the
> attacker controls the plaintext to be signed and there is no signer
> controlled text contributed there are potential bad things that could
> happen down the road.****
>
> ** **
>
> This bit us with x509 certs not that long ago (yes with MD5 admittedly)
> where the attacker could use a certificate extension to include extra data
> and cause a pre collided hash to be generated.****
>
> Having part of the signed data outside the control of an attacker is a
> good thing.  (having a nonce or message ID in the envelope is possible
> though not yet required in JWS.)****
>
> ** **
>
> I am still of the opinion that putting the base64 encoded envelope inside
> the hash calculation is a valid way to allow additional attributes.  ****
>
> Another structure to hold the attributes adds more complexity,  as would
> saying that they need to be inside the signed object.****
>
> ** **
>
> I think part of this is that as one of the openID Connect authors I look
> at this as a necessary security token format, for OAuth and Connect.  ****
>
> For that simple processing with one signature is a high priority for
> adoption.****
>
> ** **
>
> From a general signing/encrypting of documents point of view you
> legitimately have different priorities.****
>
> ** **
>
> I know it is hard to prove a negative but It is also going to be difficult
> for me to go back to security people at google Facebook and other places
> and explain how not integrity protecting the header could be better than
> integrity protecting it.****
>
> ** **
>
> It seems that I would be reduced to arguing that this is no worse than CMS
> and that hasn't been proven insecure yet.   ****
>
> ** **
>
> Allowing a possible attacker to control the hash output, and not integrity
> protecting the additional data, seems like something I am bound to regret
> in the future.****
>
> ** **
>
> Regards****
>
> John B.****
>
> ** **
>
> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote:****
>
> ** **
>
> > Hey John,****
>
> > ****
>
> > Interesting points, but I don't think they actually apply here.****
>
> > ****
>
> > With regard to downgrade attacks: ****
>
> > ****
>
> > The attack that RFC 5752 is concerned with is when an attacker strips
> signatures from a signed message, so that the only ones left are ones he
> can tamper with.  So the integrity protection here is "horizontal"; it goes
> across signatures.  The integrity protection in JWS/JWE is "vertical" -- it
> only protects one signer's parameters -- so it is, so to speak, orthogonal.
> ****
>
> > ****
>
> > ****
>
> > With regard to "brown bag" attacks:****
>
> > ****
>
> > The root of this attack is ambiguity about what content is *signed* ****
>
> > vs. what content is *used*.  If an application doesn't verify that ****
>
> > it's actually using the stuff that's signed, then it can be tricked ****
>
> > into accepting something unsigned. (Cf. ****
>
> > <http://en.wikipedia.org/wiki/Confused_Deputy>)****
>
> > ****
>
> > However, I don't think any of the current proposals have that problem.
> In JWE/JWS, the signed content is right there between the dots, and in
> JSMS, it's in the "content" element.  The current JSMS draft does allow
> detached signatures, but with a "voids your warranty" sticker on it.****
>
> > ****
>
> > In any case, these attacks have nothing to do with whether the
> cryptographic parameters are integrity-protected with the content.  The
> example attacks in the IBM still work regardless -- the whole point of the
> attack is that the cryptographic processing is the same, only the
> (non-crypto) matching of content is flawed.****
>
> > ****
>
> > ****
>
> > With regard to "arbitrary attributes":****
>
> > ****
>
> > We can have that here, too, but you need canonicalization.  And
> base64-encoding is not not canonicalization -- it just waves its hands over
> the question of equivalence.  In my opinion, we should keep the
> cryptographic object simple by disallowing attributes, and push the
> attributes you would sign inside of the thing being signed.  If people
> really do want attributes, it doesn't seem to me like JSON canonicalization
> is very hard.  I can do it in 19 lines of python: ****
>
> > <http://pastebin.com/ptUfn0c3>****
>
> > ****
>
> > ****
>
> > With regard too "meta-data in the body":****
>
> > ****
>
> > It seems to me like if we're trying to define a general format for
> applying security protections, then we ought to keep out things that aren't
> strictly security relevant.  Those things can go in application-specific
> content types (e.g., SAML) without polluting the general purpose header.
> ****
>
> > ****
>
> > ****
>
> > With regard to "defense in depth" and selling this to government
> agencies:****
>
> > ****
>
> > CMS, via S/MIME, is in broad use across multiple federal agencies and
> large enterprises.  JSMS is essentially a profile of CMS (see Section 7),
> and has the same security properties.****
>
> > ****
>
> > ****
>
> > Cheers,****
>
> > --Richard****
>
> > ****
>
> > ****
>
> > ****
>
> > ****
>
> > On Jun 19, 2012, at 5:10 PM, John Bradley wrote:****
>
> > ****
>
> >> Hi Richard,****
>
> >> ****
>
> >> Originally we only integrity protected the header for signing.  We
> added the integrity protection to encryption as part of AEAD, as encryption
> can also be used for sender verification.****
>
> >> ****
>
> >> I understand the argument that it makes things simpler if we don't
> integrity protect the header information.****
>
> >> ****
>
> >> However xmldsig,  provides integrity over those elements to prevent
> possible downgrade attacks by manipulating the algorithms.   ****
>
> >> ****
>
> >> CMS may not typically provide that integrity protection but I think Jim
> Schaad and Sean Terner created RFC5752 to address downgrade attacks.****
>
> >> Given they are on this list they can speak to their view on integrity
> over the crypto parameters.****
>
> >> ****
>
> >> I also recall when working on InfoCards there was a Monte Carlo/Brown
> Bag attack that needs to be considered if we move to something more like a
> detached signature.****
>
> >> ****
>
> >> The other design consideration is that we wanted to be able to sign
> arbitrary byte strings not just JSON.   You could sign XML if you wanted.
> ****
>
> >> That prevented us from including meta-data in the body as we didn't
> want to touch it.   That left us with the header to include additional
> elements in.  ****
>
> >> Not integrity protecting those elements as well would be a problem.  **
> **
>
> >> ****
>
> >> I am not a CMS expert but I believe it allows for signing of arbitrary
> attributes not unlike the current JOSE spec.****
>
> >> ****
>
> >> Especially for something that will be used with JWT security tokens I
> will have a hard time making the argument to NIST and others that need to
> approve this format that not integrity protecting the header parameters is
> appropriate defence in depth, for something that might be replacing signed
> SAML assertions in some applications.****
>
> >> ****
>
> >> I do understand how not integrity protecting the header will make some
> things easier, however I can't agree that the benefit outweighs the
> disadvantages.****
>
> >> ****
>
> >> Regards****
>
> >> John B.****
>
> >> ****
>
> >> ****
>
> >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote:****
>
> >> ****
>
> >>> Hey Mike,****
>
> >>> ****
>
> >>> Thanks for having some back-and-forth with me on this.  I think this
> is a good discussion to have right now.  I would like to discuss some
> high-level points, and then I'll respond inline to your precise points.***
> *
>
> >>> ****
>
> >>> tl;dr: In order to meet its deliverables, the WG needs to define
> JSON-based formats for integrity and confidentiality protections.  JWE and
> JWS don't fit that requirement, so we should re-consider their adoption and
> call for new candidates.****
>
> >>> ****
>
> >>> Major points:****
>
> >>> 1. JOSE is JSON****
>
> >>> 2. JSON does not imply canonicalization 3. Compactness and ****
>
> >>> URL-safeness are still OK, as derivatives****
>
> >>> ****
>
> >>> Part 1: JOSE is JSON****
>
> >>> ****
>
> >>> The JOSE WG charter calls out four deliverables, three of which are
> explicitly required to be JSON:****
>
> >>> -- "JSON-structured integrity protection"****
>
> >>> -- "JSON-structured encryption"****
>
> >>> -- "public keys as JSON-structured objects"****
>
> >>> (The fourth is just a list of algorithms, which should be JSON as ****
>
> >>> well, just as RFC 3370 is ASN.1.)****
>
> >>> ****
>
> >>> In light of these requirements, JWE and JWS are clearly not suitable *
> ***
>
> >>> candidates to fulfill the working group's milestones.  (At least in **
> **
>
> >>> their current form.)  So ISTM that we need to step back and ****
>
> >>> re-evaluate alternatives for the three above milestones, especially **
> **
>
> >>> the first two.  (JWK is not as far off.)****
>
> >>> ****
>
> >>> As JSON-based mechanisms, though, the "JSON serialization" drafts are
> pretty half-hearted.  Because JWS and JWE include the cryptographic
> parameters within the integrity protection, they have to have the headers
> included as base64-encoded strings.  That obviously adds a lot of
> complexity to encoding and decoding -- for example, you have to keep the
> encoded header around even after you've decoded it! -- and just plain more
> octets.  The support for multiple recipients and multiple signatures is
> both unweildy (matching up parallel indices for headers and signatures) and
> inefficient (multiple integrity check values in encrypted objects).****
>
> >>> ****
>
> >>> By contrast, JSMS takes advantage of the cryptographic wisdom that
> went into CMS, while making the syntax pure JSON and as simple as
> possible.  Multiple signatures and multiple recipients are supported with
> absolute minimum overhead.  So I think it's worth consideration by the
> working group.****
>
> >>> ****
>
> >>> ****
>
> >>> Part 2: JSON !=> canonicalization****
>
> >>> ****
>
> >>> I would like to dispel the myth that a JSON-based format requires ****
>
> >>> canonicalization.  In JWE/JWS, the JSON header requires ****
>
> >>> "canonicalization" (via base64url encoding) because it's included ****
>
> >>> within the integrity protection.  I'm not aware of any reason for ****
>
> >>> including the cryptographic parameters in the integrity check, ****
>
> >>> instead of only integrity-protecting the content itself.  Indeed, if *
> ***
>
> >>> there were an attack based on non-integrity-protected cryptographic **
> **
>
> >>> parameters, it would be a pretty big deal, since neither CMS nor IKE *
> ***
>
> >>> nor provides this protection.  (TLS does provide a signature over ****
>
> >>> the algorithms, but only as a way to bind the public key to the ****
>
> >>> session.)****
>
> >>> ****
>
> >>> Indeed CMS doesn't require canonicalization at all, except for
> attributes that are included in the protected content (signedAttrs /
> authenticatedAttrs), which need to be DER-encoded.  In JSMS, we don't allow
> those parameters, so there is no need for canonicalization at all.  All the
> "canonicalization" that's needed is to base64url-encode the protected
> content.  In that regard, JSMS is even simpler than JWE/JWS.****
>
> >>> ****
>
> >>> ****
>
> >>> Part 3: Compactness and URL-safeness are still OK, as derivatives****
>
> >>> ****
>
> >>> I have absolutely no objection to defining a compact, URL-safe
> format.  Indeed, I did so in the JSMS draft, in Section 5.  Encoding the
> example from Section 3.1 of the JWS spec, we get the following JSMS object:
> ****
>
> >>> ****
>
> >>> { ****
>
> >>>   "v":1,****
>
> >>>   "t":"au",****
>
> >>>   "a":"hs256",****
>
> >>>   "c":"eyJpc3MiOiJqb2...0cnVlfQ",****
>
> >>>   "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",****
>
> >>>   "ki":"rSIilRk8Ego"****
>
> >>> }****
>
> >>> ****
>
> >>> If we remove the decorative spaces and base64url-encode, we only use *
> ***
>
> >>> 88 octets more than JWS (267 vs. 179).  If we take this a step ****
>
> >>> further and define an explicit compact format for AuthenticatedData, *
> ***
>
> >>> we can emulate JWS by moving the content and MAC fields outside and **
> **
>
> >>> dot-combining.  That avoids double-base64url-encoding, and only ****
>
> >>> takes up 11 more octets than a JWS (190 vs 179).  (I've put the code *
> ***
>
> >>> to generate these in the Github project linked earlier.)****
>
> >>> ****
>
> >>> So it's fine to have a compact, URL-safe format for an objective, but
> it makes *much* more sense to derive that from a full-size, usable, JSON
> format than the other way around.****
>
> >>> ****
>
> >>> Responses to specific points inline below.****
>
> >>> ****
>
> >>> ****
>
> >>>> Fair enough.  I'll briefly respond to each in turn.  Before doing so,
> I'll say that I'm writing in the spirit of trying to increase mutual
> understanding and consensus, rather than taking the point of view that the
> status quo is the only reasonable outcome.****
>
> >>>> ****
>
> >>>> -- Not being JSON****
>
> >>>> ****
>
> >>>> This was by design, so that the results are URL-safe.  This is
> required, for instance, for them to be used as OAuth Bearer Tokens.  At the
> request of the working group, closely related pure-JSON drafts were also
> published.  See:****
>
> >>>> ****
>
> >>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri**
> **
>
> >>>> alization-01 and****
>
> >>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser**
> **
>
> >>>> ialization-01****
>
> >>>> ****
>
> >>>> Use them if you prefer if they better suit your use cases.  They
> could be adopted as working group documents, if there's interest.****
>
> >>> ****
>
> >>> See above.  These are super-clunky, and the need to be the main focus
> of the WG, not an afterthought.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Not supporting multiple recipients****
>
> >>>> ****
>
> >>>> The JSON serialization drafts above do, again, in response to use
> cases presented by the working group.****
>
> >>> ****
>
> >>> ****
>
> >>> See above.  Because of the unnecessary inclusion of the header in the
> integrity check, this is far less efficient than it should be.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Lacking clear distinctions between signing and MAC****
>
> >>>> ****
>
> >>>> Functionally, these are very similar operations, at least from an
> implementation perspective, so it's not clear that making a clear
> distinction would help either developers or adoption in any practical way.
> They achieve overlapping, but admittedly sometimes different goals.  I
> believe that developers can be trusted to use the algorithms that achieve
> their applications' goals without making a hard distinction between the
> two.  But I'd be interested in hearing your thoughts on why you believe a
> brighter-line distinction might be useful or necessary.****
>
> >>> ****
>
> >>> It's important if you want to do MACs with anything other than
> pre-shared keys.  If you want to do anything more advanced, you need to
> have wrapped keys, in which case an object with a MAC starts to look a lot
> more like a JWE than a JWS.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Lacking clear processing instructions for different key ****
>
> >>>> establishment modalities****
>
> >>>> ****
>
> >>>> This seems like an area where the existing drafts could be refined to
> add descriptions for additional establishment modalities, possibly based
> upon your ideas and descriptions, should the working group decide to do
> so.  What additional modalities do you have use cases for that you believe
> are not achievable or straightforward with the existing drafts?  The
> existing modalities supported are largely those that existing developers
> had told us they needed and draw both from the precursor
> draft-jones-json-web-* documents and draft-rescorla-jsms.****
>
> >>>> ****
>
> >>>> Bear in mind that the balance that the current drafts try to strike
> is keeping the Mandatory to Implement (MTI) feature footprint small enough
> that developers, including Web developers, are likely to adopt the specs,
> while still providing enough functionality to make them generally useful.
> As in any balance, it's often possible to shift things a bit and still
> maintain the balance, but I'd like people to keep the ubiquitous adoption
> goal front-and-center when proposing additional functionality.****
>
> >>>> ****
>
> >>>> Ubiquitous deployment and usefulness trump theoretical ****
>
> >>>> completeness.  (Just look at XMLDSIG and XMLENC to understand ****
>
> >>>> that!)****
>
> >>> ****
>
> >>> I agree that we need to find a reasonable MTI.  The current JSMS draft
> doesn't really specify which parts are MTI, beyond basic things like
> base64url encoding and ignoring unknown fields.****
>
> >>> ****
>
> >>> My main concern is that JWS and JWE don't really tell me which fields
> need to be present for which use case.  If I'm putting a MAC on a JWS vs. a
> signature, do I need "jwk" or "jku" fields to be populated?  Whereas in
> JSMS, I think these things are much clearer due to the separation of the
> use cases (Signed/Authenticated/Encrypted) and the isolation of signatures
> and wrapped keys into sub-objects.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Lack of clear typing of objects****
>
> >>>> ****
>
> >>>> Most JSON documents aren't clearly typed; instead, developers and
> implementations understand from context what the meaning of each field is.
> XML is clearly typed, but developers are voting with their feet by moving
> to JSON.****
>
> >>>> ****
>
> >>>> What practical advantages resulting from overlaying a typing
> infrastructure on JSON do you believe are worth the potential costs of
> doing so?  BTW, I'm not opposed to having a JSON schema description of the
> JOSE JSON data structures like JSMS did in
> http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll
> remark that this an informative tool, not a normative one.****
>
> >>> ****
>
> >>> I actualy don't have a hugely urgent requirement here either.  It's
> something that others in the WG had requested, which is trivial to add in
> JSMS, but not in JWE/JWS -- again because of the unnecessary integrity
> protection of the header.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Lack of versioning for future extensibility****
>
> >>>> ****
>
> >>>> An optional version field could be added if the working group ****
>
> >>>> desires, however the last time the working group discussed it, they *
> ***
>
> >>>> decided not to do so.  Rather, specs like this effectively become ***
> *
>
> >>>> "versioned" when revised in a way that new fields are added.  If ****
>
> >>>> you understand the new fields, you support that new version.  (Note *
> ***
>
> >>>> that this is independent of whether there is a version number ****
>
> >>>> field, which according to some participants in the previous ****
>
> >>>> discussion, they regarded as therefore being redundant ****
>
> >>>> information.)****
>
> >>>> ****
>
> >>>> I'm not religious about not having a version number field, but often
> "less is more".****
>
> >>> ****
>
> >>> Indeed, I'm not religious either.  It just seems like a general good
> idea to state this directly as opposed to having parsers divine it based on
> which fields are present.  To quote RFC 5652:****
>
> >>> "****
>
> >>>  Each of the major data structures includes a version number as the  *
> ***
>
> >>> first item in the data structure.  The version numbers are intended  *
> ***
>
> ****
> >>> version number prior to attempting a decode, and if a decode error  **
> **
>
> >>> occurs, then the version number is checked as part of the error  ****
>
> >>> handling routine.  This is a reasonable approach; it places error  ***
> *
>
> >>> processing outside of the fast path.  This approach is also ****
>
> >>> forgiving  when an incorrect version number is used by the sender.****
>
> >>> "****
>
> >>> ****
>
> >>> ****
>
> >>> Best,****
>
> >>> --Richard****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>>> ****
>
> >>>>                                                   Best wishes,****
>
> >>>>                                                   -- Mike****
>
> >>>> ****
>
> >>>> -----Original Message-----****
>
> >>>> From: Richard L. Barnes [mailto:[email-masked]]****
>
> >>>> Sent: Friday, June 15, 2012 3:00 PM****
>
> >>>> To: Mike Jones****
>
> >>>> Cc: [email-masked]****
>
> >>>> Subject: Re: [jose] Fwd: New Version Notification for ****
>
> >>>> draft-barnes-jose-jsms-00.txt****
>
> >>>> ****
>
> >>>> Ok, so maybe I should have phrased my lead-in differently.  IMO, the
> current JW* specs are deficient in several ways, e.g.:****
>
> >>>> -- Not being JSON****
>
> >>>> -- Not supporting multiple recipients****
>
> >>>> -- Lacking clear distinctions between signing and MAC****
>
> >>>> -- Lacking clear processing instructions for different key ****
>
> >>>> establishment modalities****
>
> >>>> -- Lack of clear typing of objects****
>
> >>>> -- Lack of versioning for future extensibility****
>
> >>>> ****
>
> >>>> Looking at the current specs, it didn't seem to me that it would be
> simple to adapt them to address these deficiencies.  So I just did a
> re-write.  If you think they can be addressed within the current framework,
> please explain.  I just found it simpler to start from whole cloth.****
>
> >>>> ****
>
> >>>> Cheers,****
>
> >>>> --Richard****
>
> >>>> ****
>
> >>>> ****
>
> >>>> ****
>
> >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:****
>
> >>>> ****
>
> >>>>> Hi Richard,****
>
> >>>>> ****
>
> >>>>> If you're puzzled by specific design decisions in the JOSE
> documents, I encourage you to ask about them on the list.  The documents
> have significant history going back to mid-2010 when convergence
> discussions started among people with four different JSON signing &
> encryption proposals.  JWT and the current JOSE specs and implementations
> are the result.  I realize that not all the JOSE participants were part of
> those discussions from the beginning (although many were) and so teasing
> out the rationale for specific decisions might help people better
> understand the choices made, and hopefully thereby increase consensus
> behind the eventual working group choices.****
>
> >>>>> ****
>
> >>>>> If the list that you're puzzled by is the bulleted list below, maybe
> we can start a discussion on that basis.****
>
> >>>>> ****
>
> >>>>>                                                 Best wishes,****
>
> >>>>>                                                 -- Mike****
>
> >>>>> ****
>
> >>>>> -----Original Message-----****
>
> >>>>> From: [email-masked] [mailto:[email-masked]] On ****
>
> >>>>> Behalf Of Richard L. Barnes****
>
> >>>>> Sent: Friday, June 15, 2012 2:08 PM****
>
> >>>>> To: [email-masked]****
>
> >>>>> Subject: [jose] Fwd: New Version Notification for ** **
>
> >>>>> draft-barnes-jose-jsms-00.txt****
>
> >>>>> ****
>
> >>>>> Dear JOSE WG,****
>
> >>>>> ****
>
> >>>>> Like Mr. Manger, once I finally got around to doing a thorough
> review of the JW* specs, I was kind of puzzled by some of the design
> decisions.  So I also went through and wrote an alternative format, this
> time taking a more of a cue from CMS.  A link to the document is below.***
> *
>
> >>>>> ****
>
> >>>>> Summary of differences:****
>
> >>>>> ****
>
> >>>>> o  JSMS is pure JSON, whereas in JWE and JWS only the header****
>
> >>>>>   parameters are represented in JSON.****
>
> >>>>> ****
>
> ****
> >>>>>   only allows ECDH-ES.****
> >>>>> ****
> >>>>> o  JSMS supports multiple recipients for EncryptedData and****
>
> ****
> >>>>>   objects.  Sending a JWE to multiple recipients requires re-****
>
> >>>>>   encryption of the entire object for each recipient.****
>
> >>>>> ****
>
> >>>>> o  The signature and MAC functions of the JWS object are separated**
> **
>
> >>>>>   into SignedData and AuthenticatedData JSMS objects.****
>
> >>>>> ****
>
> >>>>> o  JSMS parameters are not integrity-protected, as they are in JWE**
> **
>
> >>>>>   and JWS.****
>
> >>>>> ****
>
> ****
> >>>>>   be added without significant change.****
>
> >>>>> ****
>
> >>>>> o  JSMS requires that recipients MUST ignore unknown header****
>
> >>>>>   parameters, in order to facilitate extensibility.****
>
> >>>>> ****
>
> >>>>> I've also thrown together an initial JavaScript implementation
> (based on NodeJS for some python crypto glue), which is on github:****
>
> >>>>> <https://github.com/bifurcation/jsms>****
>
> >>>>> ****
>
> >>>>> Comments are very welcome.  ****
>
> >>>>> ****
>
> >>>>> Thanks,****
>
> >>>>> --Richard****
>
> >>>>> ****
>
> >>>>> ****
>
> >>>>> ****
>
> >>>>> Begin forwarded message:****
>
> >>>>> ****
>
> >>>>>> From: [email-masked]****
>
> >>>>>> Subject: New Version Notification for ****
>
> >>>>>> draft-barnes-jose-jsms-00.txt****
>
> >>>>>> Date: June 15, 2012 4:56:09 PM EDT****
>
> >>>>>> To: [email-masked]****
>
> >>>>>> ****
>
> >>>>>> ****
>
> >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been ****
>
> >>>>>> successfully submitted by Richard Barnes and posted to the IETF ***
> *
>
> >>>>>> repository.****
>
> >>>>>> ****
>
> >>>>>> Filename:             draft-barnes-jose-jsms****
>
> >>>>>> Revision:              00****
>
> >>>>>> Title:                     JavaScript Message Security Format****
>
> >>>>>> Creation date:    2012-06-15****
>
> >>>>>> WG ID:                  Individual Submission****
>
> >>>>>> Number of pages: 25****
>
> >>>>>> URL:
> http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt****
>
> >>>>>> Status:
> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms****
>
> >>>>>> Htmlized:
> http://tools.ietf.org/html/draft-barnes-jose-jsms-00****
>
> >>>>>> ****
>
> >>>>>> ****
>
> >>>>>> Abstract:****
>
> >>>>>> Many applications require the ability to send cryptographically ***
> *
>
> >>>>>> secured messages.  While the IETF has defined a number of formats *
> ***
>
> >>>>>> for such messages (e.g.  CMS) those formats use encodings which ***
> *
>
> >>>>>> are not easy to use in modern applications.  This document ****
>
> >>>>>> describes the JavaScript Message Security format (JSMS), a new ****
>
> >>>>>> cryptographic message format which is based on JavaScript Object **
> **
>
> >>>>>> Notation (JSON) and thus is easy for many applications to generate
> and parse.****
>
> >>>>>> ****
>
> >>>>>> ****
>
> >>>>>> ****
>
> >>>>>> ****
>
> >>>>>> The IETF Secretariat****
>
> >>>>> ****
>
> >>>>> _______________________________________________****
>
> >>>>> jose mailing list****
>
> >>>>> [email-masked]****
>
> >>>>> https://www.ietf.org/mailman/listinfo/jose****
>
> >>>>> ****
>
> >>>>> ****
>
> >>>>> _______________________________________________****
>
> >>>>> jose mailing list****
>
> >>>>> [email-masked]****
>
> >>>>> https://www.ietf.org/mailman/listinfo/jose****
>
> >>>> ****
>
> >>>> ****
>
> >>>> ****
>
> >>>> _______________________________________________****
>
> >>>> jose mailing list****
>
> >>>> [email-masked]****
>
> >>>> https://www.ietf.org/mailman/listinfo/jose****
>
> >>> ****
>
> >>> _______________________________________________****
>
> >>> jose mailing list****
>
> >>> [email-masked]****
>
> >>> https://www.ietf.org/mailman/listinfo/jose****
>
> >> ****
>
> > ****
>
> ** **
>
> [email-masked]

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jun 2012 17:34:40 -0400

Hi Nat, 

I'm not sure what X.509 fiasco you're referring to.  There was a recent MD5 fiasco [1], but that's an attack on MD5, not X.509.  In fact, there have been recommendations for preventing this attack in X.509 since 2005 [2].  As was noted on the SAAG list, the real news here is that Microsoft wasn't following any of those recommendations.

JWS would have had the same problem as X.509.  The attack did not modify the cryptographic parameters (anything that would have gone in the header), it would not have been thwarted by the integrity protection we're worrying about.  

Actually, the header signing that JWS does makes it even nicer for the attacker: Flame used a "chosen prefix" attack, so since the JWS header value is entirely static for a given signer, it's easy to use as a fixed prefix.  If JWS just signed the content, then the application could include a something random up front to prevent such prefix-based attacks.

It's tempting to say that we should just add randomness to the JOSE format.  But the real lesson of the Flame/MD5 attacks is operational:  If you're signing something that somebody else gave you, make sure that you're not signing exactly what they gave you.  Follow the recommendations of RFC 4270.  In other contexts, there's no need of similar random elements; it just adds complexity.  

--Richard

[1] <http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf>
[2] <http://tools.ietf.org/html/rfc4270#section-5.1>

On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote:

> Especially after the X.509 fiasco, I strongly believe that having integrity check over the metadata is a good thing. It is such a little effort that gives us much more protection down the road. In this sense, I fully agree with Ben here. We should have integrity protection over the header. 
> 
> Nat
> 
> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones <[email-masked]> wrote:
> He argued that if the parameters can be protected in a practical manner, then they should.  Doing so provides an additional hurdle that attackers would have to surmount.  For example, if they can try to substitute a weaker authentication scheme, then they must figure out how to make it authenticate correctly despite some plaintext they can't control – the header parameters.
> 
>  
> 
> ·  What to sign (envelope.payload or just payload)?
> 
> Given that the envelope is extensible and therefore may contain security-sensitive information, we reached a consensus (with input from Ben Laurie via IM) that the combination envelope.payload must be signed.
>  
> 
> For all these reasons, I therefore personally stand by the community’s decision to provide integrity protection for the headers.
> 
>  
> 
>                                                             Best wishes,
> 
>                                                             -- Mike
> 
>  
> 
> 
> >>>> From: Richard L. Barnes [mailto:[email-masked]]
> 
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> 
> >>>>> To: [email-masked]
> >>>>>> From: [email-masked]
> 
> >>>>>> To: [email-masked]

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 25 Jun 2012 16:48:00 -0700

<personal>

Richard,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard L. Barnes
> Sent: Monday, June 25, 2012 2:35 PM
> To: Nat Sakimura
> Cc: Mike Jones; [email-masked]
> I'm not sure what X.509 fiasco you're referring to.  There was a recent
MD5
> fiasco [1], but that's an attack on MD5, not X.509.  In fact, there have
been
> recommendations for preventing this attack in X.509 since 2005 [2].  As
was
> noted on the SAAG list, the real news here is that Microsoft wasn't
following
> any of those recommendations.
> 
> JWS would have had the same problem as X.509.  The attack did not modify
> the cryptographic parameters (anything that would have gone in the
> header), it would not have been thwarted by the integrity protection we're
> worrying about.
> 
> Actually, the header signing that JWS does makes it even nicer for the
> attacker: Flame used a "chosen prefix" attack, so since the JWS header
value
> is entirely static for a given signer, it's easy to use as a fixed prefix.
If JWS just
> signed the content, then the application could include a something random
> up front to prevent such prefix-based attacks.
> 

I don't believe that this is a true statement.  If you had a prefix or just
signed what was given to you (i.e. no prefix), it would make no difference
in terms of the attack for Flame.  Flame could always use a fixed prefix of
its own design rather than using the fixed header that is generated by
having JWS sign the header information.

> It's tempting to say that we should just add randomness to the JOSE
format.
> But the real lesson of the Flame/MD5 attacks is operational:  If you're
signing
> something that somebody else gave you, make sure that you're not signing
> exactly what they gave you.  Follow the recommendations of RFC 4270.  In
> other contexts, there's no need of similar random elements; it just adds
> complexity.

This is definitely a true statement in all events and is something that
should be added to the Security Considerations section.

That being said, I think that there are valid reasons for wanting to protect
the header information by some authentication processing.  PKIX certificates
protect the signature algorithm information (by copying the data into the to
be signed block) and CMS has long allowed for information to be included in
the signed attributes area that identifies the algorithms used, the
certificates used and so forth.  There are also other things that we might
find to be convenient to be placed in the header information that is current
not there (a signing time and embedded content type comes to mind) that
would be a product either of specific types of signatures or becomes a
common attribute to be placed there.

In terms of encryption operations, I remember in the past that I have had
either corrupted encrypted streams or corrupted IVs and had a successful
decryption that later generated other problems when trying to parse.  This
is less of an issue with AEAD algorithms as they have a much stricter rule
on when the stream decrypts correctly.

Jim

> check over the metadata is a good thing. It is such a little effort that
gives us
> much more protection down the road. In this sense, I fully agree with Ben
> here. We should have integrity protection over the header.
> >
> > Nat
> >
> > Two years ago when the developer community needing a JSON-friendly
> token format was designing the JSON Web Token (JWT), we explicitly asked
> security experts whether the header parameters should be integrity
> protected or not.  Among them, Ben Laurie was one of the voices saying
that
> securing them was the right thing to do.
> >
> >
> >
weaker
> authentication scheme, then they must figure out how to make it
> authenticate correctly despite some plaintext they can't control - the
header
> parameters.
least
> you can get away with, given attacks you can think of, is not a good
design
> principle.  If there is not a strong argument against including a feature
that
> may make it harder for attackers, then that feature should be included.
> >
> >
> >
> > I agree with him.
> >
> >
> >
> in the session notes at http://self-issued.info/?p=361, which said:
> >
> >
> >
> > .  What to sign (envelope.payload or just payload)?
> >
security-
> sensitive information, we reached a consensus (with input from Ben Laurie
> via IM) that the combination envelope.payload must be signed.
> >
> >
> > For all these reasons, I therefore personally stand by the community's
> decision to provide integrity protection for the headers.
> >
> >
> >
> >                                                             Best wishes,
> >
> >                                                             -- Mike
> >
> >
> >
> >
> susceptible to modification with ECDH or RSA-PSS it is not.
> >
> as an example (I know we preclude truncated hashes at the moment).
> >
> >
> >
controlled
> text contributed there are potential bad things that could happen down the
> road.
> >
> >
> >
and
> cause a pre collided hash to be generated.
> >
good
> thing.  (having a nonce or message ID in the envelope is possible though
not
> yet required in JWS.)
> the hash calculation is a valid way to allow additional attributes.
> >
> saying that they need to be inside the signed object.
> >
> >
> >
at this
> as a necessary security token format, for OAuth and Connect.
> >
adoption.
> legitimately have different priorities.
> >
> >
> >
> > I know it is hard to prove a negative but It is also going to be
difficult for me
> to go back to security people at google Facebook and other places and
> explain how not integrity protecting the header could be better than
> integrity protecting it.
> >
> >
> >
> and that hasn't been proven insecure yet.
> >
> >
> >
in
> the future.
can
> tamper with.  So the integrity protection here is "horizontal"; it goes
across
> signatures.  The integrity protection in JWS/JWE is "vertical" -- it only
protects
> one signer's parameters -- so it is, so to speak, orthogonal.
> >
> > >
> >
> > >
> >
JSMS,
> it's in the "content" element.  The current JSMS draft does allow detached
> signatures, but with a "voids your warranty" sticker on it.
> >
> > >
> >
(non-crypto)
> matching of content is flawed.
> >
> > >
> >
> > >
> >
base64-
> encoding is not not canonicalization -- it just waves its hands over the
> question of equivalence.  In my opinion, we should keep the cryptographic
> object simple by disallowing attributes, and push the attributes you would
> sign inside of the thing being signed.  If people really do want
attributes, it
> doesn't seem to me like JSON canonicalization is very hard.  I can do it
in 19
> lines of python:
applying
> security protections, then we ought to keep out things that aren't
strictly
> security relevant.  Those things can go in application-specific content
types
> (e.g., SAML) without polluting the general purpose header.
> >
> > >
> >
> > >
> >
> agencies:
and
> has the same security properties.
> >
> > >
> >
> > >
> >
> > > Cheers,
> >
> > > --Richard
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
added
> the integrity protection to encryption as part of AEAD, as encryption can
also
> be used for sender verification.
> >
> > >>
> >
> integrity protect the header information.
> >
> > >>
> >
> possible downgrade attacks by manipulating the algorithms.
> >
> > >>
> >
> Schaad and Sean Terner created RFC5752 to address downgrade attacks.
> >
over
> the crypto parameters.
> detached signature.
elements
> in.
> attributes not unlike the current JOSE spec.
> >
> > >>
> >
will
> have a hard time making the argument to NIST and others that need to
> SAML assertions in some applications.
> >
> > >>
> >
> disadvantages.
is a
> good discussion to have right now.  I would like to discuss some
high-level
> points, and then I'll respond inline to your precise points.
> >
> > >>>
> >
JSON-
> based formats for integrity and confidentiality protections.  JWE and JWS
> don't fit that requirement, so we should re-consider their adoption and
call
> for new candidates.
> explicitly required to be JSON:
> >
> > >>> As JSON-based mechanisms, though, the "JSON serialization" drafts
> are pretty half-hearted.  Because JWS and JWE include the cryptographic
complexity
> to encoding and decoding -- for example, you have to keep the encoded
> header around even after you've decoded it! -- and just plain more octets.
> The support for multiple recipients and multiple signatures is both
unweildy
> (matching up parallel indices for headers and signatures) and inefficient
> (multiple integrity check values in encrypted objects).
> >
> > >>>
> >
possible.
> Multiple signatures and multiple recipients are supported with absolute
> minimum overhead.  So I think it's worth consideration by the working
group.
> authenticatedAttrs), which need to be DER-encoded.  In JSMS, we don't
> allow those parameters, so there is no need for canonicalization at all.
All the
> content.  In that regard, JSMS is even simpler than JWE/JWS.
> >
> > >>>
> >
> > >>>
> >
format.
> Indeed, I did so in the JSMS draft, in Section 5.  Encoding the example
from
> Section 3.1 of the JWS spec, we get the following JSMS object:
> >
> > >>>
> >
> > >>> {
> >
> > >>>   "v":1,
> >
> > >>>   "t":"au",
> >
> > >>>   "a":"hs256",
> >
> > >>> So it's fine to have a compact, URL-safe format for an objective,
but it
> makes *much* more sense to derive that from a full-size, usable, JSON
> format than the other way around.
> >
> > >>>
> >
> > >>>> Fair enough.  I'll briefly respond to each in turn.  Before doing
so, I'll
> say that I'm writing in the spirit of trying to increase mutual
understanding
> and consensus, rather than taking the point of view that the status quo is
the
> only reasonable outcome.
required,
> for instance, for them to be used as OAuth Bearer Tokens.  At the request
of
> the working group, closely related pure-JSON drafts were also published.
> See:
> >
> > >>>>
> >
could
> be adopted as working group documents, if there's interest.
> >
> > >>>
> >
> cases presented by the working group.
> >
> > >>>
> >
> > >>>
> >
> integrity check, this is far less efficient than it should be.
> >
> > >>>
> >
> > >>>
> >
distinction
> would help either developers or adoption in any practical way.  They
achieve
> overlapping, but admittedly sometimes different goals.  I believe that
> developers can be trusted to use the algorithms that achieve their
> applications' goals without making a hard distinction between the two.
But
> I'd be interested in hearing your thoughts on why you believe a
brighter-line
> distinction might be useful or necessary.
> >
> > >>>
> >
> > >>> It's important if you want to do MACs with anything other than pre-
> shared keys.  If you want to do anything more advanced, you need to have
> wrapped keys, in which case an object with a MAC starts to look a lot more
> like a JWE than a JWS.
> >
> > >>>
> >
> > >>>
> >
so.
> What additional modalities do you have use cases for that you believe are
> not achievable or straightforward with the existing drafts?  The existing
> modalities supported are largely those that existing developers had told
us
> they needed and draw both from the precursor draft-jones-json-web-*
> documents and draft-rescorla-jsms.
> >
> > >>>>
> >
is
> keeping the Mandatory to Implement (MTI) feature footprint small enough
As
> in any balance, it's often possible to shift things a bit and still
maintain the
> balance, but I'd like people to keep the ubiquitous adoption goal
front-and-
> center when proposing additional functionality.
> >
> > >>>>
> >
base64url
> encoding and ignoring unknown fields.
> >
> > >>>
> >
JSMS,
> I think these things are much clearer due to the separation of the use
cases
> (Signed/Authenticated/Encrypted) and the isolation of signatures and
> wrapped keys into sub-objects.
> >
> > >>>
> >
> > >>>
> >
to
> JSON.
doing
> so?  BTW, I'm not opposed to having a JSON schema description of the JOSE
> JSON data structures like JSMS did in http://tools.ietf.org/html/draft-
> rescorla-jsms-00#appendix-A, but I'll remark that this an informative
tool, not
> a normative one.
> protection of the header.
> >
> > >>>
> >
> > >>>
> >
> "less is more".
idea
> to state this directly as opposed to having parsers divine it based on
which
> fields are present.  To quote RFC 5652:
> >
> > >>> "
> >
> current JW* specs are deficient in several ways, e.g.:
> >
> > >>>> -- Not being JSON
> >
re-write.
> If you think they can be addressed within the current framework, please
> explain.  I just found it simpler to start from whole cloth.
> >
> > >>>>
> >
> > >>>> Cheers,
> >
> > >>>> --Richard
> >
> > >>>>
> >
> > >>>>
> >
> > >>>>
> >
documents,
> I encourage you to ask about them on the list.  The documents have
> significant history going back to mid-2010 when convergence discussions
> started among people with four different JSON signing & encryption
> proposals.  JWT and the current JOSE specs and implementations are the
> result.  I realize that not all the JOSE participants were part of those
> discussions from the beginning (although many were) and so teasing out the
> rationale for specific decisions might help people better understand the
> choices made, and hopefully thereby increase consensus behind the
> eventual working group choices.
> >
> > >>>>>
> >
> > >>>>> If the list that you're puzzled by is the bulleted list below,
maybe we
> can start a discussion on that basis.
> >
> > >>>>>
> >
> > >>>>>                                                 Best wishes,
> >
> > >>>>>                                                 -- Mike
> >
> > >>>>>
> >
time
> taking a more of a cue from CMS.  A link to the document is below.
> >
> > >>>>>
> >
> > >>>>> Summary of differences:
> >
> > >>>>>
> >
(based
> on NodeJS for some python crypto glue), which is on github:
> >
http://www.ietf.org/internet-drafts/draft-barnes-jose-
> jsms-00.txt
http://datatracker.ietf.org/doc/draft-barnes-jose-jsms
> > >>>>>> Htmlized:
http://tools.ietf.org/html/draft-barnes-jose-jsms-00
> and parse.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jun 2012 19:59:41 -0400

Jim,

Now that we are mandating JWE sender verification people will be using JWE with symmetric keys or key agreement.
In those cases one can easily argue that the header should be protected as much as in HMAC.

There may well be signing_time or other elements that would go into the header as well for JWE.

Regards
John B.

On 2012-06-25, at 7:48 PM, Jim Schaad wrote:

>> John Bradley

---

From: Richard L. Barnes <[email-masked]>
Date: Tue, 26 Jun 2012 13:42:03 -0400

> having JWS sign the header information.

I'm not sure I agree.  It's not really useful to speculate with full generality.  Flame didn't choose the format; X.509/PKIX did.  So we have to imagine that the attacker is exploiting an existing signed object format.  My point is that JWS defeats protections that such applications apply.

Suppose we have something like X.509 that we want to sign with JWS.  The application does the right thing and randomizes things at the beginning like serial numbers and validity dates.  If the application content were signed under CMS or JSMS, the encapsulated content would be just be the application content C.  If it were signed with JWS, the encapsulated content would be "H.C", where H is the large, predictable JWS header.  So even if the application tries to defend itself, JWS makes it vulnerable to prefix attacks.

(From this perspective, even CMS signed parameters are harmful, in terms of creating fixed prefixes.  It's somewhat less than JWS, however, because they're (1) shorter, and (2) binary.)  

> common attribute to be placed there.

If we want to enable signed attributes, I would be OK with that.  One thing about *not* having mandatory header protection is that if an application feels that it needs header protection, then it can copy the headers it's concerned about into the body.  Enabling integrity-protected attributes in JOSE is one approach, which would save applications some of the burden of figuring out how to include things in the body.  Personally, I would rather punt on this for now.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 13:43:16 -0400

> In those cases one can easily argue that the header should be protected as much as in HMAC.

Can you clarify the scope of "we are mandating"?

> There may well be signing_time or other elements that would go into the header as well for JWE.

Why do these need to go into the header rather than the body?

--Richard

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 15:30:09 -0400

There was a WG decision to not allow encryption without integrity.   Jim and others call that sender verification.

Or on simple terms no AES-CBC without a mandatory MAC integrity.

The JWE/JWS specs don't control the body.   That is intended to be arbitrary content.

We do have s JWT spec that covers the body for security tokens.   The idea was to separate that from signing and encryption so that signing and encryption can be used for other objects.

John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 15:33:33 -0400

> Or on simple terms no AES-CBC without a mandatory MAC integrity.

Thanks.  I remembered the "AEAD-only" agreement, but didn't know the "sender verification" term.  

> We do have s JWT spec that covers the body for security tokens.   The idea was to separate that from signing and encryption so that signing and encryption can be used for other objects.

That's exactly my point.  You can have something like JWT specify a body format that has the protected parameters, so why does JWS/JWE need integrity-protected attributes?

--Richard

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Jun 2012 20:30:21 +0000

Not sure there was a WG decision and what that would mean if there was, as there are many libraries out there that don't support the encryption with integrity algorithms, so need to support alternative means of things like key wrap that could have an integrity check.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, June 26, 2012 12:30 PM
To: Richard L. Barnes
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

John B.

On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote:

>>>> Subject: Re: [jose] New Version Notification for 
>>>> draft-barnes-jose-jsms- 00.txt
>>>> 
>>>> Hi Nat,
>>>> 
>>>> JWS would have had the same problem as X.509.  The attack did not 
>>>> modify the cryptographic parameters (anything that would have gone 
>>>> in the header), it would not have been thwarted by the integrity 
>>>> protection we're worrying about.
>>>> 
>>>> signed the content, then the application could include a something 
>>>> random up front to prevent such prefix-based attacks.
>>>> 
>>> 
>>> I don't believe that this is a true statement.  If you had a prefix 
>>> or just signed what was given to you (i.e. no prefix), it would make 
>>> no difference in terms of the attack for Flame.  Flame could always 
>>> use a fixed prefix of its own design rather than using the fixed 
>>> header that is generated by having JWS sign the header information.
>>> 
>>>> something that somebody else gave you, make sure that you're not 
>>>> signing exactly what they gave you.  Follow the recommendations of 
>>>> RFC 4270.  In other contexts, there's no need of similar random 
>>>> elements; it just adds complexity.
>>> 
>>> This is definitely a true statement in all events and is something 
>>> that should be added to the Security Considerations section.
>>> 
>>> That being said, I think that there are valid reasons for wanting to 
>>> protect the header information by some authentication processing.  
>>> PKIX certificates protect the signature algorithm information (by 
>>> copying the data into the to be signed block) and CMS has long 
>>> allowed for information to be included in the signed attributes area 
>>> that identifies the algorithms used, the certificates used and so 
>>> forth.  There are also other things that we might find to be 
>>> convenient to be placed in the header information that is current 
>>> not there (a signing time and embedded content type comes to mind) 
>>> that would be a product either of specific types of signatures or becomes a common attribute to be placed there.
>>> 
>>> In terms of encryption operations, I remember in the past that I 
>>> have had either corrupted encrypted streams or corrupted IVs and had 
>>> a successful decryption that later generated other problems when 
>>> trying to parse.  This is less of an issue with AEAD algorithms as 
>>> they have a much stricter rule on when the stream decrypts correctly.
>>> 
>>> Jim
>>> 
>>>> 
>>>> --Richard
>>>> 
>>>> 
>>>> 
>>>> much more protection down the road. In this sense, I fully agree 
>>>> token format was designing the JSON Web Token (JWT), we explicitly 
>>>> asked security experts whether the header parameters should be 
>>>> integrity protected or not.  Among them, Ben Laurie was one of the 
>>>> voices saying
>>> that
>>>> then they should.  Doing so provides an additional hurdle that 
>>>> attackers would have to surmount.  For example, if they can try to 
>>>> substitute a
>>> weaker
>>>> sensitive information, we reached a consensus (with input from Ben 
>>>> Laurie via IM) that the combination envelope.payload must be signed.
>>>>> 
>>>>> 
>>>>>                                                          Best 
>>>>> wishes,
>>>>> Behalf Of
>>>>> Subject: Re: [jose] New Version Notification for 
>>>>> draft-barnes-jose-jsms-
>>>> 00.txt
>>>>> 
>>>>> 
>>>>> 
>>>>> Hi Richard,
>>>>> 
>>>>> 
>>>>> 
>>>>> The bad feeling I get around this is that if there is a scenario 
>>>>> where
>>> the
>>>> text contributed there are potential bad things that could happen 
>>>> down the road.
>>>>> 
>>>>> 
>>>>> 
>>>> to go back to security people at google Facebook and other places 
>>>> and explain how not integrity protecting the header could be better 
>>>> than integrity protecting it.
>>>>> 
>>>>> 
>>>>> 
>>>>> It seems that I would be reduced to arguing that this is no worse 
>>>>> than
>>> CMS
>>>> it's in the "content" element.  The current JSMS draft does allow 
>>>> detached signatures, but with a "voids your warranty" sticker on it.
>>>>> 
>>>>>> 
>>>>> 
>>>> cryptographic parameters are integrity-protected with the content.  
>>>> The example attacks in the IBM still work regardless -- the whole 
>>>> point of the attack is that the cryptographic processing is the 
>>>> same, only the
>>> (non-crypto)
>>>> encoding is not not canonicalization -- it just waves its hands 
>>>> over the question of equivalence.  In my opinion, we should keep 
>>>> the cryptographic object simple by disallowing attributes, and push 
>>>> the attributes you would sign inside of the thing being signed.  If 
>>>> people really do want
>>> attributes, it
>>>>>>> CMS may not typically provide that integrity protection but I 
>>>>>>> think
>>> Jim
>>>> Bag attack that needs to be considered if we move to something more 
>>>> like a detached signature.
>>>>> 
>>>>>>> 
>>>>> 
>>>> have a hard time making the argument to NIST and others that need 
>>>> to approve this format that not integrity protecting the header 
>>>> parameters is appropriate defence in depth, for something that 
>>>> might be replacing signed SAML assertions in some applications.
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> I do understand how not integrity protecting the header will 
>>>>>>> make
>>> some
>>>> based formats for integrity and confidentiality protections.  JWE 
>>>> and JWS don't fit that requirement, so we should re-consider their 
>>>> adoption and
>>> call
>>>> for new candidates.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> Major points:
>>>>> 
>>>>>>>> 1. JOSE is JSON
>>>>> 
>>>> are pretty half-hearted.  Because JWS and JWE include the 
>>>> cryptographic parameters within the integrity protection, they have 
>>>> to have the headers included as base64-encoded strings.  That 
>>>> obviously adds a lot of
>>> complexity
>>>> to encoding and decoding -- for example, you have to keep the 
>>>> encoded header around even after you've decoded it! -- and just plain more octets.
>>>> (matching up parallel indices for headers and signatures) and 
>>>> inefficient (multiple integrity check values in encrypted objects).
>>>>> 
>>>>>>>> 
>>>>> 
>>>> Multiple signatures and multiple recipients are supported with 
>>>> absolute minimum overhead.  So I think it's worth consideration by 
>>>> the working
>>> group.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> 
>>>>> 
>>>> attributes that are included in the protected content (signedAttrs 
>>>> / authenticatedAttrs), which need to be DER-encoded.  In JSMS, we 
>>>> don't allow those parameters, so there is no need for canonicalization at all.
>>> All the
>>>> "canonicalization" that's needed is to base64url-encode the 
>>>> protected content.  In that regard, JSMS is even simpler than JWE/JWS.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> If we remove the decorative spaces and base64url-encode, we 
>>>>>>>> only
>>>> use
>>>>> 
>>>> makes *much* more sense to derive that from a full-size, usable, 
>>>> JSON format than the other way around.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> See above.  Because of the unnecessary inclusion of the header 
>>>>>>>> in
>>> the
>>>> overlapping, but admittedly sometimes different goals.  I believe 
>>>> that developers can be trusted to use the algorithms that achieve 
>>>> their applications' goals without making a hard distinction between the two.
>>> But
>>>>>>>> pre-
>>>> shared keys.  If you want to do anything more advanced, you need to 
>>>> have wrapped keys, in which case an object with a MAC starts to 
>>>> look a lot more like a JWE than a JWS.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>>> This seems like an area where the existing drafts could be 
>>>>>>>>> refined
>>> to
>>>> add descriptions for additional establishment modalities, possibly 
>>>> based upon your ideas and descriptions, should the working group 
>>>> decide to do
>>> so.
>>>> What additional modalities do you have use cases for that you 
>>>> believe are not achievable or straightforward with the existing 
>>>> drafts?  The existing modalities supported are largely those that 
>>>> existing developers had told
>>> us
>>>> keeping the Mandatory to Implement (MTI) feature footprint small 
>>>> enough that developers, including Web developers, are likely to 
>>>> adopt the specs, while still providing enough functionality to make them generally useful.
>>> As
>>>>>>>> I agree that we need to find a reasonable MTI.  The current 
>>>>>>>> JSMS
>>> draft
>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures 
>>>> and wrapped keys into sub-objects.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> 
>>>>> 
>>>> so?  BTW, I'm not opposed to having a JSON schema description of 
>>>> the JOSE JSON data structures like JSMS did in 
>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, but 
>>>> I'll remark that this an informative
>>> tool, not
>>>> a normative one.
>>>>> 
>>>>>>>> 
>>>>> 
>>>> something that others in the WG had requested, which is trivial to 
>>>> add in JSMS, but not in JWE/JWS -- again because of the unnecessary 
>>>> integrity protection of the header.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> to avoid ASN.1 decode errors.  Some implementations do not 
>>>>>>>> check
>>>> the
>>>>> 
>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently.  
>>>>>>>>> IMO,
>>> the
>>>> If you think they can be addressed within the current framework, 
>>>> please explain.  I just found it simpler to start from whole cloth.
>>>>> 
>>>>>>>>> 
>>>>> 
>>>>>>>>> Cheers,
>>>>> 
>>>>>>>>> --Richard
>>>>> 
>>>>>>>>> 
>>>>> 
>>>>>>>>> 
>>>>> 
>>>>>>>>> 
>>>>> 
>>>> significant history going back to mid-2010 when convergence 
>>>> encryption proposals.  JWT and the current JOSE specs and 
>>>> implementations are the result.  I realize that not all the JOSE 
>>>> participants were part of those discussions from the beginning 
>>>> (although many were) and so teasing out the rationale for specific 
>>>> decisions might help people better understand the choices made, and 
>>>> hopefully thereby increase consensus behind the eventual working group choices.
>>>>> 
>>>>>>>>>> 
>>>>> 
>>>> review of the JW* specs, I was kind of puzzled by some of the 
>>>> design decisions.  So I also went through and wrote an alternative 
>>>> format, this
>>> time
>>>>>>>>>> o  JSMS allows for full algorithm agility in key agreement, 
>>>>>>>>>> while
>>> JWE
>>>>> 
>>>>>>>>>> only allows ECDH-ES.
>>>>> 
>>>>>>>>>> 
>>>>> 
>>>>>>>>>> o  The "typ" and "zip" parameters are not defined in JSMS, 
>>>>>>>>>> but
>>> could
>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 16:58:55 -0400

Yes that is why we added the composite HMAC + AES-CBC.   We can debate if that is an algorithm or mandatory integrity with non AEAD algorithms, but the effect of integrity protecting the header remains in both cases.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Jun 2012 21:03:02 +0000

AES-ECB is also a popular alternative

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2012 1:59 PM
To: Anthony Nadalin
Cc: Richard L. Barnes; Jim Schaad; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 17:07:02 -0400

You should suggest adding that as a supported algorithm.

We wanted to keep the core set down to a reasonable number to encourage interoparability.

AES-ECB + HMAC can be a option if the WG wants it.

John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 17:20:16 -0400

Why would you ever want to use ECB mode?  If you want something fast and parallelizable, CTR mode is a lot better.

We had discussed Dave McGrew's draft as a mechanism for specifying general AEAD algorithms:
<http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1>

--Richard

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Jun 2012 21:23:47 +0000

Because it's in most libraries and it works well for key wrap and it's in a lot of products. That's fine to discuss (and did not say it was not discussed) but I don't recall reaching a consensus on that point yet.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Tuesday, June 26, 2012 2:20 PM
To: John Bradley
Cc: Anthony Nadalin; Jim Schaad; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

--Richard

On Jun 26, 2012, at 5:07 PM, John Bradley wrote:

>>>>>>> JWS would have had the same problem as X.509.  The attack did 
>>>>>>> not modify the cryptographic parameters (anything that would 
>>>>>>> have gone in the header), it would not have been thwarted by the 
>>>>>>> integrity protection we're worrying about.
>>>>>>> 
>>>>>>> signed the content, then the application could include a 
>>>>>>> something random up front to prevent such prefix-based attacks.
>>>>>>> 
>>>>>> 
>>>>>> I don't believe that this is a true statement.  If you had a 
>>>>>> prefix or just signed what was given to you (i.e. no prefix), it 
>>>>>> would make no difference in terms of the attack for Flame.  Flame 
>>>>>> could always use a fixed prefix of its own design rather than 
>>>>>> using the fixed header that is generated by having JWS sign the header information.
>>>>>> 
>>>>>>> signing exactly what they gave you.  Follow the recommendations 
>>>>>>> of RFC 4270.  In other contexts, there's no need of similar 
>>>>>>> random elements; it just adds complexity.
>>>>>> 
>>>>>> This is definitely a true statement in all events and is 
>>>>>> something that should be added to the Security Considerations section.
>>>>>> 
>>>>>> That being said, I think that there are valid reasons for wanting 
>>>>>> to protect the header information by some authentication processing.
>>>>>> allowed for information to be included in the signed attributes 
>>>>>> area that identifies the algorithms used, the certificates used 
>>>>>> and so forth.  There are also other things that we might find to 
>>>>>> be convenient to be placed in the header information that is 
>>>>>> current not there (a signing time and embedded content type comes 
>>>>>> to mind) that would be a product either of specific types of signatures or becomes a common attribute to be placed there.
>>>>>> 
>>>>>> have had either corrupted encrypted streams or corrupted IVs and 
>>>>>> had a successful decryption that later generated other problems 
>>>>>> when trying to parse.  This is less of an issue with AEAD 
>>>>>> algorithms as they have a much stricter rule on when the stream decrypts correctly.
>>>>>> 
>>>>>> Jim
>>>>>> 
>>>>>>> 
>>>>>>> --Richard
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> [1] 
>>>>>>> <http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf>
>>>>>>>> Especially after the X.509 fiasco, I strongly believe that 
>>>>>>>> having
>>>>>> integrity
>>>>>>> token format was designing the JSON Web Token (JWT), we 
>>>>>>> explicitly asked security experts whether the header parameters 
>>>>>>> should be integrity protected or not.  Among them, Ben Laurie 
>>>>>>> was one of the voices saying
>>>>>> that
>>>>>>> attackers would have to surmount.  For example, if they can try 
>>>>>>> to substitute a
>>>>>> weaker
>>>>>>> sensitive information, we reached a consensus (with input from 
>>>>>>> Ben Laurie via IM) that the combination envelope.payload must be signed.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> There are possible hash truncation attacks by shortening SHA256 
>>>>>>>> to
>>>>>> SHA224
>>>>>>>> The bad feeling I get around this is that if there is a 
>>>>>>>> scenario where
>>>>>> the
>>>>>>> text contributed there are potential bad things that could 
>>>>>>> happen down the road.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I am still of the opinion that putting the base64 encoded 
>>>>>>>> envelope
>>>>>> inside
>>>>>>> to go back to security people at google Facebook and other 
>>>>>>> places and explain how not integrity protecting the header could 
>>>>>>> be better than integrity protecting it.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> It seems that I would be reduced to arguing that this is no 
>>>>>>>> worse than
>>>>>> CMS
>>>>>>>> Allowing a possible attacker to control the hash output, and 
>>>>>>>> not
>>>>>> integrity
>>>>>>> it's in the "content" element.  The current JSMS draft does 
>>>>>>> allow detached signatures, but with a "voids your warranty" sticker on it.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> The example attacks in the IBM still work regardless -- the 
>>>>>>> whole point of the attack is that the cryptographic processing 
>>>>>>> is the same, only the
>>>>>> (non-crypto)
>>>>>>> the cryptographic object simple by disallowing attributes, and 
>>>>>>> push the attributes you would sign inside of the thing being 
>>>>>>> signed.  If people really do want
>>>>>> attributes, it
>>>>>>> Bag attack that needs to be considered if we move to something 
>>>>>>> more like a detached signature.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> have a hard time making the argument to NIST and others that 
>>>>>>> need to approve this format that not integrity protecting the 
>>>>>>> header parameters is appropriate defence in depth, for something 
>>>>>>> that might be replacing signed SAML assertions in some applications.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> things easier, however I can't agree that the benefit outweighs 
>>>>>>> the disadvantages.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> Regards
>>>>>>>> 
>>>>>>>>>> John B.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> based formats for integrity and confidentiality protections.  
>>>>>>> JWE and JWS don't fit that requirement, so we should re-consider 
>>>>>>> their adoption and
>>>>>> call
>>>>>>> for new candidates.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> Major points:
>>>>>>>> 
>>>>>>>>>>> 1. JOSE is JSON
>>>>>>>> 
>>>>>>> cryptographic parameters within the integrity protection, they 
>>>>>>> have to have the headers included as base64-encoded strings.  
>>>>>>> That obviously adds a lot of
>>>>>> complexity
>>>>>>> absolute minimum overhead.  So I think it's worth consideration 
>>>>>>> by the working
>>>>>> group.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> attributes that are included in the protected content 
>>>>>>> (signedAttrs / authenticatedAttrs), which need to be 
>>>>>>> DER-encoded.  In JSMS, we don't allow those parameters, so there is no need for canonicalization at all.
>>>>>> All the
>>>>>>>>>>> we can emulate JWS by moving the content and MAC fields 
>>>>>>>>>>> outside
>>>>>>> and
>>>>>>>> 
>>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-j
>>>>>>>>>>>> son
>>>>>>>>>>>> -seri
>>>>>>>> 
>>>>>>>>>>>> alization-01 and
>>>>>>>> 
>>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-
>>>>>>>>>>>> jso
>>>>>>>>>>>> n-ser
>>>>>>>> 
>>>>>>>>>>>> ialization-01
>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> See above.  These are super-clunky, and the need to be the 
>>>>>>>>>>> main
>>>>>>> focus of the WG, not an afterthought.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> See above.  Because of the unnecessary inclusion of the 
>>>>>>>>>>> header in
>>>>>> the
>>>>>>> overlapping, but admittedly sometimes different goals.  I 
>>>>>>> believe that developers can be trusted to use the algorithms 
>>>>>>> that achieve their applications' goals without making a hard distinction between the two.
>>>>>> But
>>>>>>> shared keys.  If you want to do anything more advanced, you need 
>>>>>>> to have wrapped keys, in which case an object with a MAC starts 
>>>>>>> to look a lot more like a JWE than a JWS.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> add descriptions for additional establishment modalities, 
>>>>>>> possibly based upon your ideas and descriptions, should the 
>>>>>>> working group decide to do
>>>>>> so.
>>>>>>> drafts?  The existing modalities supported are largely those 
>>>>>>> that existing developers had told
>>>>>> us
>>>>>>> they needed and draw both from the precursor 
>>>>>>> draft-jones-json-web-* documents and draft-rescorla-jsms.
>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> My main concern is that JWS and JWE don't really tell me 
>>>>>>>>>>> which
>>>>>> fields
>>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, 
>>>>>>> but I'll remark that this an informative
>>>>>> tool, not
>>>>>>> a normative one.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> something that others in the WG had requested, which is trivial 
>>>>>>> to add in JSMS, but not in JWE/JWS -- again because of the 
>>>>>>> unnecessary integrity protection of the header.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>>> I'm not religious about not having a version number field, 
>>>>>>>>>>>> but
>>>>>> often
>>>>>>> "less is more".
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> I encourage you to ask about them on the list.  The documents 
>>>>>>> discussions started among people with four different JSON 
>>>>>>> signing & encryption proposals.  JWT and the current JOSE specs 
>>>>>>> and implementations are the result.  I realize that not all the 
>>>>>>> JOSE participants were part of those discussions from the 
>>>>>>> beginning (although many were) and so teasing out the rationale 
>>>>>>> for specific decisions might help people better understand the 
>>>>>>> choices made, and hopefully thereby increase consensus behind the eventual working group choices.
>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> design decisions.  So I also went through and wrote an 
>>>>>>> alternative format, this
>>>>>> time
>>>>>>>>>>>>> o  JSMS allows for full algorithm agility in key 
>>>>>>>>>>>>> agreement, while
>>>>>> JWE
>>>>>>>> 
>>>>>>>>>>>>> only allows ECDH-ES.
>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 17:29:03 -0400

I am not proposing adding any algorithms.   

If people want additional algorithms in JWA then they should propose them.

My point was simply that in light of the problems with AES-CBC the WG decided that all non AEAD algorithms include the HMAC integrity protection we have defined in JWE.

That integrity protection makes use of the CMK and a key derivation algorithm to generate a CEK and CIK.

If someone for reasons I don't personally care about wanted ECB they could propose that in the same way we now have AES-CBC defined.

We are not precluding non AEAD block cyphers only mandating integrity be used with them.

We currently have a HMAC-SHA256 + AES-CBC mechanism,  others are not precluded,  just not specified in the JWA at the moment.

Regards
John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 17:34:47 -0400

Not to rat-hole on ECB, but:

I would be interested to hear about libraries that support ECB, but not other modes.

Key wrap does not use ECB.  It uses AES as a primitive, mixing in entropy over multiple rounds.
<http://tools.ietf.org/html/rfc3394#section-2.2.1>

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 17:35:14 -0400

The integrity check is not required for Key Wrap.   

At the moment AES128KW and AES256KW  are what is specified in JWA.  
Again if people want to extend the KW algs there is nothing to stop them making proposals.

Oh look it's 5:30 and I have to wash my hair.

I look forward to rejoining the debate tomorrow:)

Regards
John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Jun 2012 15:35:49 -0700

> There was a WG decision to not allow encryption without integrity.   Jim
and
> others call that sender verification.

Jim would not call that sender verification.  Jim would call that integrity
protection on the transmitted content.  There is no concept of data
origination with any type of AE algorithm.

> The JWE/JWS specs don't control the body.   That is intended to be
arbitrary
> content.
> 
> We do have s JWT spec that covers the body for security tokens.   The idea
> was to separate that from signing and encryption so that signing and
> encryption can be used for other objects.
> 
> John B.
> 
> >> Now that we are mandating JWE sender verification people will be using
> JWE with symmetric keys or key agreement.
> >>>> Subject: Re: [jose] New Version Notification for draft-barnes-jose-
> jsms-
> >>>> 00.txt
> >>>>
> >>>> Hi Nat,
> >>>>
> modify
> random
that
> >>> That being said, I think that there are valid reasons for wanting to
protect
> >>> protect the signature algorithm information (by copying the data into
the
> asked
attackers
> Laurie
wishes,
> >>>>> Subject: Re: [jose] New Version Notification for draft-barnes-jose-
> jsms-
> >>>> 00.txt
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hi Richard,
> >>>>>
> >>>>>
> >>>>>
where
> down the
than
> detached
> The
> >>>> example attacks in the IBM still work regardless -- the whole point
of
think
> cryptographic
> encoded
inefficient
> >>>> Multiple signatures and multiple recipients are supported with
absolute
> >>>> and consensus, rather than taking the point of view that the status
quo
> json-ser
that
> have
> based
> enough
> >>>> need to be present for which use case.  If I'm putting a MAC on a JWS
> vs.
> >>> a
add
> please
> discussions
while

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Jun 2012 22:36:09 +0000

Key wrap can be done with AES in ECB mode. I did not say there are libraries that support ECB and no other modes, just answered the question you asked.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Tuesday, June 26, 2012 2:35 PM
To: Anthony Nadalin
Cc: John Bradley; Jim Schaad; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

On Jun 26, 2012, at 5:23 PM, Anthony Nadalin wrote:

>>>> Behalf Of John Bradley
>>>>>>>> have gone in the header), it would not have been thwarted by 
>>>>>>>> the integrity protection we're worrying about.
>>>>>>>> 
>>>>>>> would make no difference in terms of the attack for Flame.  
>>>>>>> Flame could always use a fixed prefix of its own design rather 
>>>>>>> than using the fixed header that is generated by having JWS sign the header information.
>>>>>>> 
>>>>>>>> something that somebody else gave you, make sure that you're 
>>>>>>>> not signing exactly what they gave you.  Follow the 
>>>>>>>> recommendations of RFC 4270.  In other contexts, there's no 
>>>>>>>> need of similar random elements; it just adds complexity.
>>>>>>> 
>>>>>>> That being said, I think that there are valid reasons for 
>>>>>>> wanting to protect the header information by some authentication processing.
>>>>>>> PKIX certificates protect the signature algorithm information 
>>>>>>> (by copying the data into the to be signed block) and CMS has 
>>>>>>> long allowed for information to be included in the signed 
>>>>>>> attributes area that identifies the algorithms used, the 
>>>>>>> certificates used and so forth.  There are also other things 
>>>>>>> that we might find to be convenient to be placed in the header 
>>>>>>> information that is current not there (a signing time and 
>>>>>>> embedded content type comes to mind) that would be a product either of specific types of signatures or becomes a common attribute to be placed there.
>>>>>>> 
>>>>>>>> much more protection down the road. In this sense, I fully 
>>>>>>>> agree with Ben here. We should have integrity protection over the header.
>>>>>>>>> 
>>>>>>>>> Nat
>>>>>>>>> 
>>>>>>>> authenticate correctly despite some plaintext they can't 
>>>>>>>> control
>>>>>>>> - the
>>>>>>> header
>>>>>>>> parameters.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The decision to provide integrity protection for the headers 
>>>>>>>>> is
>>>>>>> documented
>>>>>>>>> There are possible hash truncation attacks by shortening 
>>>>>>>>> SHA256 to
>>>>>>> SHA224
>>>>>>>> places and explain how not integrity protecting the header 
>>>>>>>> could be better than integrity protecting it.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> over the question of equivalence.  In my opinion, we should 
>>>>>>>> keep the cryptographic object simple by disallowing attributes, 
>>>>>>>> and push the attributes you would sign inside of the thing 
>>>>>>>> being signed.  If people really do want
>>>>>>> attributes, it
>>>>>>>>>>> CMS may not typically provide that integrity protection but 
>>>>>>>>>>> I think
>>>>>>> Jim
>>>>>>>> header parameters is appropriate defence in depth, for 
>>>>>>>> something that might be replacing signed SAML assertions in some applications.
>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> JWE and JWS don't fit that requirement, so we should 
>>>>>>>> re-consider their adoption and
>>>>>>> call
>>>>>>>> for new candidates.
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>> Major points:
>>>>>>>>> 
>>>>>>>>>>>> 1. JOSE is JSON
>>>>>>>>> 
>>>>>>>> makes *much* more sense to derive that from a full-size, 
>>>>>>>> usable, JSON format than the other way around.
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> shared keys.  If you want to do anything more advanced, you 
>>>>>>>> need to have wrapped keys, in which case an object with a MAC 
>>>>>>>> starts to look a lot more like a JWE than a JWS.
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> keeping the Mandatory to Implement (MTI) feature footprint 
>>>>>>>> small enough that developers, including Web developers, are 
>>>>>>>> likely to adopt the specs, while still providing enough functionality to make them generally useful.
>>>>>>> As
>>>>>>>> (Signed/Authenticated/Encrypted) and the isolation of 
>>>>>>>> signatures and wrapped keys into sub-objects.
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> so?  BTW, I'm not opposed to having a JSON schema description 
>>>>>>>> of the JOSE JSON data structures like JSMS did in
>>>>>>>> If you think they can be addressed within the current 
>>>>>>>> framework, please explain.  I just found it simpler to start from whole cloth.
>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>>>>>> --Richard
>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> have significant history going back to mid-2010 when 
>>>>>>>> convergence discussions started among people with four 
>>>>>>>> different JSON signing & encryption proposals.  JWT and the 
>>>>>>>> current JOSE specs and implementations are the result.  I 
>>>>>>>> realize that not all the JOSE participants were part of those 
>>>>>>>> discussions from the beginning (although many were) and so 
>>>>>>>> teasing out the rationale for specific decisions might help 
>>>>>>>> people better understand the choices made, and hopefully thereby increase consensus behind the eventual working group choices.
>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>> o  The "typ" and "zip" parameters are not defined in 
>>>>>>>>>>>>>> JSMS, but
>>>>>>> could
>>>>>>>>> 
>>>>>>>>>>>>>>> secured messages.  While the IETF has defined a number 
>>>>>>>>>>>>>>> of
>>>>>>>> formats
>>>>>>>>> 
>>>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications 
>>>>>>>>>>>>>>> to
>>>>>>> generate
>>>>>>>> and parse.
>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Jun 2012 15:39:42 -0700

Under what circumstances would people use ECB?  

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2012 2:03 PM
> To: John Bradley
> Subject: RE: [jose] New Version Notification for draft-barnes-jose-jsms-
> 00.txt
> 
> Yes that is why we added the composite HMAC + AES-CBC.   We can debate if
> that is an algorithm or mandatory integrity with non AEAD algorithms, but
the
> effect of integrity protecting the header remains in both cases.
> 
> John B.
> 
> > Not sure there was a WG decision and what that would mean if there was,
> as there are many libraries out there that don't support the encryption
with
> integrity algorithms, so need to support alternative means of things like
key
> wrap that could have an integrity check.
> >
> and others call that sender verification.
> >
arbitrary
> >>> In those cases one can easily argue that the header should be
protected
> as much as in HMAC.
> >>>> or just signed what was given to you (i.e. no prefix), it would
> >>>> make no difference in terms of the attack for Flame.  Flame could
> >>>> always use a fixed prefix of its own design rather than using the
> >>>> fixed header that is generated by having JWS sign the header
> information.
> >>>>
> >>>> area that identifies the algorithms used, the certificates used and
> >>>> so forth.  There are also other things that we might find to be
> >>>> that would be a product either of specific types of signatures or
> becomes a common attribute to be placed there.
> >>>>
> >>>>> and explain how not integrity protecting the header could be
> >>>>> better than integrity protecting it.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> have to have the headers included as base64-encoded strings.  That
> >>>>> obviously adds a lot of
> >>>> complexity
> >>>>> don't allow those parameters, so there is no need for
canonicalization
> at all.
> >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-jso
> >>>>>>>>>> n
> >>>>>>>>>> -seri
> >>>>>>
> >>>>>>>>>> alization-01 and
> >>>>>>
> >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-js
> >>>>>>>>>> o
> >>>>>>>>>> n-ser
> >>>>>>
> >>>>>>>>>> ialization-01
> >>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>> to have wrapped keys, in which case an object with a MAC starts to
> >>>>> add in JSMS, but not in JWE/JWS -- again because of the
> >>>>> discussions started among people with four different JSON signing
> >>>>> & encryption proposals.  JWT and the current JOSE specs and
> >>>>> decisions might help people better understand the choices made,
> >>>>> and hopefully thereby increase consensus behind the eventual
> working group choices.
> >>>>>>
> >>>>>>>>>>>
> >>>>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Jun 2012 22:43:33 +0000

Used all the time as its quicker than CBC mocde very simple if I have just 1 block of data 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, June 26, 2012 3:40 PM
To: Anthony Nadalin; 'John Bradley'
Cc: 'Richard L. Barnes'; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

> Subject: RE: [jose] New Version Notification for 
the
with
key
arbitrary
protected
> >>> There may well be signing_time or other elements that would go 
> >>> into
> the header as well for JWE.
> >>
> >>>>> is entirely static for a given signer, it's easy to use as a 
> >>>>> fixed
prefix.
> >>>> using the fixed header that is generated by having JWS sign the 
> >>>> header
> information.
> >>>>
> >>>> to mind) that would be a product either of specific types of 
> >>>> signatures or
> >>>>> DER-encoded.  In JSMS, we don't allow those parameters, so there 
> >>>>> is no need for
canonicalization
> >>>>>>>>>> so
> >>>>>>>>>> js
> >>>>> that achieve their applications' goals without making a hard 
> >>>>> distinction between
> the two.
> >>>> But
> >>>>> adopt the specs, while still providing enough functionality to 
> >>>>> make
> them generally useful.
> >>>> As
> >>>>> need to be present for which use case.  If I'm putting a MAC on 
> >>>>> a
JWS
> >>>>> choices made, and hopefully thereby increase consensus behind 
> >>>>> the eventual
> working group choices.
> >>>>>>
> >>>>>>>>>>>
> >>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2012 18:50:54 -0400

Sorry, I meant Authenticated Encryption from your earlier email to the list.

> 
> The AEAD algorithm class is called Authenticated encryption with additional
> data.  This is the term for the art.  Note that this does not imply sender
> origination which is the additional service one wants signatures for.  There
> is a debate if you get sender origination even with static-static key
> agreement.

I was not trying to imply identification of the sender.

Though debate or not,  people use HMAC with symmetric keys to infer sender, I suspect that they will do the same with AEAD or CBC+HMAC.

That argues for equivalent integrity protection of the header in encryption as signing, to my mind.

Sorry I got the term wrong.

John B.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 27 Jun 2012 12:18:17 +1000

Richard Barnes wrote (in the thread "Re: [jose] New Version Notification for	draft-barnes-jose-jsms-00.txt"):
> You can have something like JWT specify a
> body format that has the protected parameters, so why does JWS/JWE need
> integrity-protected attributes?

One attribute is whether or not the content of this JWS/JWE is another JWS/JWE. This attribute is more a part of the JWS/JWE processing than metadata for the content.

For instance, if a sender signs-then-encrypts content it would be good if an attacker cannot change it to appear to be just encrypted content.

Is it too unlikely that a receiving app will mistake a JWS for the content it expected? If an app expected a JSON object as the content (eg as per JWT) but got a JWS, is it conceivable that it could mistake the JWS header for the JWT?

--
James Manger

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Jun 2012 21:49:38 -0400

> For instance, if a sender signs-then-encrypts content it would be good if an attacker cannot change it to appear to be just encrypted content.

Can you describe what attack this would prevent?  

Again noting precedent: If you look at S/MIME, for example, the Content-Type of the MIME body is inside of the CMS EnvelopedData structure, so the presence of SignedData on the inside would not be observable.

> Is it too unlikely that a receiving app will mistake a JWS for the content it expected? If an app expected a JSON object as the content (eg as per JWT) but got a JWS, is it conceivable that it coul…

In general, applications that use JOSE are going to need to specify what the protected content must be.  I think that if the above question arises, then the application protocol is underspecified.

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Jun 2012 23:33:49 -0700

> Sent: Wednesday, June 27, 2012 6:50 PM
> To: Manger, James H
> Cc: [email-masked]
> Subject: Re: [jose] protected attributes
> 
> 
> >> You can have something like JWT specify a body format that has the
> >> protected parameters, so why does JWS/JWE need integrity-protected
> >> attributes?
> >
> >
> > One attribute is whether or not the content of this JWS/JWE is another
> JWS/JWE. This attribute is more a part of the JWS/JWE processing than
> metadata for the content.
> >
> > For instance, if a sender signs-then-encrypts content it would be good
if an
> attacker cannot change it to appear to be just encrypted content.
> 
> Again noting precedent: If you look at S/MIME, for example, the Content-
> Type of the MIME body is inside of the CMS EnvelopedData structure, so the
> presence of SignedData on the inside would not be observable.
> 

True and false - If you look at S/MIME you would see an id-data, however if
you look at CMS you might see id-SignedData as the encapsulated content
type.  For S/MIME it would be data - since the next wrapping layer is mime
not SignedData.

Jim

> 
> > Is it too unlikely that a receiving app will mistake a JWS for the
content it
> expected? If an app expected a JSON object as the content (eg as per JWT)
> but got a JWS, is it conceivable that it could mistake the JWS header for
the
> JWT?
> 
> In general, applications that use JOSE are going to need to specify what
the
> protected content must be.  I think that if the above question arises,
then
> the application protocol is underspecified.
> 
> --Richard

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 28 Jun 2012 17:42:57 +1000

Richard,

>>> One attribute is whether or not the content of this JWS/JWE is
>>> another JWS/JWE. This attribute is more a part of the JWS/JWE
>>> processing than metadata for the content.
>>>
>>> For instance, if a sender signs-then-encrypts content it would be
>>> good if an attacker cannot change it to appear to be just encrypted
>>> content.

>> Can you describe what attack this would prevent?

I can describe a somewhat artificial attack.
Alice creates a message
  {"iss":"Bob","perm":"read","alg":"RS256"}.{"iss":"Bob","perm":"write",...}
Alice says it is a "JWT bag of claims" and asks Bob to sign it.
Bob expects a JSON object so only "sees" the first part.
He confirms Alice does have "read" permission,
confirms he is listed as the issuer, and accepts anything else
as unverified user-asserted stuff (like a lot of details in 
public certificates).
Bob signs the message, prepending an unprotected header with the
details.

Alice modifies the unprotected JOSE header,
adding "embed":true to Bob's header.

Charlie receives the message and passes it to his JOSE library.
The library verifies Bob's signature, interprets the content
as another JOSE message, verifies Alice's signature, and passes
back to Charlie {"iss":"Bob","perm":"write",...} plus metadata saying
it was signed by Bob and Alice.
Charlie trusts Bob and hence gives Alice write access.
ATTACK SUCCEEDED

This only works if a block of data can be interpreted as a
valid JOSE message by one party and as valid application
content by another party. That is a bit unusual but far from
impossible. Concatenate a *.GIF and a *.ZIP file and you
get a valid image and a valid ZIP archive (since they are
parsed from the start & end respectively).

Without protecting the "embed" attribute JOSE gives:

              [       ]    [       ] -----> INVALID
 content ---> [ JOSE  ] -> [ JOSE  ] -or--> content
              [ wrap  ]    [unwrap ] -or--> intermediate content

It would be nice not to need to rely on application
logic to distinguish "intermediate content" from
the actual "content". That is, the 3rd option should be
detected as INVALID (eg by signing the "embed" attribute).

>> Again noting precedent: If you look at S/MIME, for example, the
>> Content-Type of the MIME body is inside of the CMS EnvelopedData
>> structure, so the presence of SignedData on the inside would not
>> be observable.

> True and false - If you look at S/MIME you would see an id-data,
> however if you look at CMS you might see id-SignedData as the
> encapsulated content type.  For S/MIME it would be data - since
> the next wrapping layer is mime not SignedData.

So does every app using JOSE need to define a MIME-like encapsulation
around its content (like S/MIME does) to use JOSE safely?
What are the necessary features of that encapsulation?

--
James Manger

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jun 2012 10:16:10 -0400

Hey James,

There are a few problems with this scenario.  

> Bob signs the message, prepending an unprotected header with the

Most clearly, Bob is being irresponsible.  He should not be signing anything that he doesn't want to assert.  Before he signs, he should be verifying that he understands and agrees with everything in the assertion.  Bob should have signed only the part that he "saw".  (Read the contract before you sign it!)  Attacks that rely on irresponsible signer practices call for operational guidelines, not protocol changes.

> adding "embed":true to Bob's header.

There's no such thing as an unprotected header in JWS.  

What is "embed"?  I don't see it in the JWT or JWS specs:
<http://tools.ietf.org/html/draft-jones-json-web-token-10>
<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02>

> Charlie trusts Bob and hence gives Alice write access.

I don't see where Alice signed anything in this example.  Maybe you could flesh it out a little?

> detected as INVALID (eg by signing the "embed" attribute).

I don't think it's unreasonable to have the application define what it is that's inside the protected content.  You can do this either by having something inside the protected content that says what it is (in which case it's protected), or by fixing the type in the application specification (and verifying this on receipt).

S/MIME follows the first pattern, by having an inner Content-Type that tells you what the protected MIME entity is.  Matt Miller's XMPP e2e security draft follows the second pattern, requiring the protected content to be an XMPP <message> stanza.
<http://tools.ietf.org/html/draft-miller-xmpp-e2e-01>

For something like JWT, I would think you would just do the latter, and require that the inner body be a set of claims, formatted in JSON. 

> What are the necessary features of that encapsulation?

See above.  The application needs to either specify the type of the protected content in-band (like S/MIME) or define a fixed content type (like XMPP).

--Richard

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 29 Jun 2012 15:56:30 +1000

> Most clearly, Bob is being irresponsible.  He should not be signing
> anything that he doesn't want to assert.  Before he signs, he should be
> verifying that he understands and agrees with everything in the
> assertion.  Bob should have signed only the part that he "saw".  (Read
> the contract before you sign it!)  Attacks that rely on irresponsible
> signer practices call for operational guidelines, not protocol changes.

Bob is not necessarily being quite as irresponsible as he seems.

Any CA will sign 256 bytes that I can choose almost arbitrarily
as long as I say the bytes are a 2048-bit RSA modulus.
The CA isn't irresponsible, even if those 256 bytes are the
UTF-8 encoding of "This CA promises to give you $1M…".
This is only safe because a DER-encoded TBSCertificate has so
much structure that it is inconceivable that those bytes could
be misinterpreted as some other application message.

It is not absolutely clear to me that a JOSE message
(in whatever syntax we end up with) will have so much structure
that it is inconceivable that a value could be created that
was both a valid JOSE message and a valid application message
simultaneously.

> There's no such thing as an unprotected header in JWS.

The whole idea of this thread was to discuss your suggestion
to replace JWS with a syntax that had an unprotected header.

> What is "embed"?  I don't see it in the JWT or JWS specs:

"embed":true is one possible way to indicate that the content
is another JOSE message, not the final content.
Dick Hardt suggested an "emb" element in the JSON header,
instead of my suggestion of using the case (upper or lower)
of a prefix (E.<header>... or e.<header>...).
The current specs use "typ":"JWS" for the indication.
Sorry for the confusion.

> could flesh it out a little?

{"iss":"Bob","perm":"read","alg":"RS256"...}.{"iss":"Bob","perm":"write",...}.<signature>

Alice creates this message. It is a valid JOSE signed message (eg "alg":"RS256" in header), with some extra fields (eg "perm":"read") that are unrecognized (hence ignored) by a JOSE receiver.

This same message is also a valid application message from Bob's perspective. Perhaps Bob ignores the fields like "alg" that his app doesn't recognized (just like the JOSE processor ignores the "perm" field), or perhaps the extra stuff is user-chosen like the modulus in a certificate.

Bob adds a layer of JOSE protection to the message and expects Charlie to remove just this layer. Charlie however removes both Bob's and Alice's JOSE layers since the indication of another layer in Bob's header was not protected so it could be modified. Charlie verifies that the message is from Bob, and the final content has "perm":"write".

> I don't think it's unreasonable to have the application define what it
> is that's inside the protected content.  You can do this either by
> having something inside the protected content that says what it is (in
> which case it's protected), or by fixing the type in the application
> specification (and verifying this on receipt).
> 
> S/MIME follows the first pattern, by having an inner Content-Type that
> tells you what the protected MIME entity is.  Matt Miller's XMPP e2e
> security draft follows the second pattern, requiring the protected
> content to be an XMPP <message> stanza.
> For something like JWT, I would think you would just do the latter, and
> require that the inner body be a set of claims, formatted in JSON.
> 
> 
> See above.  The application needs to either specify the type of the
> protected content in-band (like S/MIME) or define a fixed content type
> (like XMPP).

"define a fixed content type" AND ensure no value can simultaneously look like a value of that fixed content type and a JOSE message.

--
James Manger

---

From: Stephen Kent <[email-masked]>
Date: Fri, 29 Jun 2012 12:11:34 -0400

At 3:56 PM +1000 6/29/12, Manger, James H wrote:
>  > ...

really? I would argue that any CA that signs an object without verifying
that the object is a well-formed cert (or CRL) is 
a pretty poor example of a CA.
Also, what the CA signs, literally, is a hash of the object, not an RSA
modulus, so I'm confused by your text above.

I would agree with the statement that many (most?) CAs that use HSMs
are employing hardware that will sign whatever it is handed, without
being able to verify what it is. That's a different statement from what
you said above.

>UTF-8 encoding of "This CA promises to give you $1MŠ".

again, disagree.

>be misinterpreted as some other application message.

OK, we're getting closer to reality here.

>was both a valid JOSE message and a valid application message

That may be a valid concern, depending on the syntax. if the syntax of
Jose objects is well-specified and declared, then this concern seems
unwarranted.

Steve

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 29 Jun 2012 13:52:35 -0400

Top-posting two points for emphasis:

1. This problem could be avoided if JWT provided a way to distinguish a claims object from a JWS, e.g., by putting the "emb" field *inside* the object. 

2. Nested signatures are an *awful* solution in this case.  If you want to have two people sign the same set of claims, parallel signatures would be much cleaner.  Consider also the "canonicalization bloat": If N people sign, then the content gets base64-encoded N times, each time increasing the length by a factor of ~1.5-2x.  Compare this to just adding a Signature object in JSMS.  <http://tools.ietf.org/html/draft-barnes-jose-jsms-00#section-4.3.1>

JWS: Exponential cost
JSMS: Linear cost 

The choice seems clear to me :)  (I admit that the JSON serialization of JWS supports multiple parallel signers, so it's linear too.)

Further replies inline.

> was both a valid JOSE message and a valid application message

That's why it's important for the application to specify what the content is that's being handled, and not just to say "Oh, it could be a JWS, or it could be something else, you'll have to guess."  

Your attack doesn't work in PKIX because the specification says "The thing that's signed is a TBSCertificate, so these 256 octets are a public key, so you should uses them like a public key, not a string."

Your attack does work in JWS (with unprotected headers) because JWT doesn't say what the interior octets are.

This is not an issue of collisions between formats, it's an issue of having sufficient specification that the recipient knows what he's getting.  If there's agreement between the signer and the recipient about what the thing is, then collisions don't matter.

> to replace JWS with a syntax that had an unprotected header.

Oh, ok, sorry :)

> "define a fixed content type" AND ensure no value can simultaneously look like a value of that fixed content type and a JOSE message.

If the content type is fixed, then there's no need to avoid collision with JOSE: The content is always processed as the fixed content type, never as a JOSE message.  Likewise if the content type is specified, as in S/MIME; the content is always processed as the specified content type.  That is, it's processed as JOSE only if the (protected) content-type says it's JOSE.

The only context where the protocol needs to worry about collisions is if it *allows* them -- that is, it follows neither of the design patterns above, and just allows either JOSE or content without a signifier.

To offer a concrete example, JWT could avoid this whole problem by requiring that the inner JSON object contain a field "emb":true, indicating whether the JSON is another JWS or the claims themselves (and defaulting to false, obviously).  That would be functionally equivalent to putting it in a protected header value, but carry along all the problems with signing cryptographic parameters. 

--Richard