Subject: Re: [jose] #36: Algorithm "none" should be removed

From: "jose issue tracker" <[email-masked]>
Date: Thu, 01 Aug 2013 10:32:52 -0000

#36: Algorithm "none" should be removed

Comment (by [email-masked]):

 There's plenty of precedent in IETF protocols for algorithm identifiers
 like "alg":"none".  For instance, TLS (RFC 5246) defines the cipher suite
 TLS_NULL_WITH_NULL_NULL in which "encryption consists of the identity
 operation".  It even defines a hash algorithm called "none".

 No, these aren't appropriate to use in many application contexts.  But
 that's no reason not to enable the use of "alg":"none" in contexts where
 it meets the security requirements of the application.

 The verification algorithm is simple for "alg":"none: - if the JWS
 Signature field is empty, return SUCCESS.  If the signature field is non-
 empty, reject the input.  I can add that to the spec.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [email-masked] |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  signature              |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/36#comment:3>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 01 Aug 2013 11:23:17 -0000

Comment (by [email-masked]):

 And sure enough, working groups across the IETF are having to explicitly
 forbid the use of null ciphersuites.  They provide empirical evidence that
 this design pattern is a bad idea.

 As I've pointed out before, you can add that verification algorithm, but
 you will not have a good time writing security considerations around it.
 Checking that you support "none" is not enough -- you have to check that
 *nothing* *else* in the header could possibly indicate that a different
 signature algorithm should be used.

 So we have something that (1) causes a lot of spec work, (2) causes
 security vulnerabilities under likely implementaiton designs, and (3) has
 no use case, and (4) will haunt us for years to come (how many times do
 you want to write 'MUST NOT use "alg":"none"'?).  Sounds like a recipe for
 success!

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/36#comment:4>
jose <http://tools.ietf.org/jose/>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 1 Aug 2013 11:51:49 +0000

If something doesn't have a signature (or MAC, yeah yeah yeah), then I have a really hard time calling it a JWS (JSON Web Signature), and there fore have a really hard time seeing "alg":"none" as useful.

Assuming this is using compact serialization: Why not just send in the base64url(payload)?  Then you can tell if you have an actually signed JWT (3 dots) versus an unsigned JWT (0 dots).

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On Aug 1, 2013, at 1:23 PM, jose issue tracker <[email-masked]> wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 14:03:20 +0200

If you really want to have a header, you could also have the unsigned JWT
have 2 components (1 dot).  That way, you would demux
unsigned/signed/encrypted based on number of dots, not "alg".

--Richard

On Thu, Aug 1, 2013 at 1:51 PM, Matt Miller (mamille2)
<[email-masked]>wrote:

> If something doesn't have a signature (or MAC, yeah yeah yeah), then I
> have a really hard time calling it a JWS (JSON Web Signature), and there
> fore have a really hard time seeing "alg":"none" as useful.
>
> Assuming this is using compact serialization: Why not just send in the
> base64url(payload)?  Then you can tell if you have an actually signed JWT
> (3 dots) versus an unsigned JWT (0 dots).
>
>
> - m&m
>
> > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/36#comment:4
> >

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Aug 2013 12:10:57 +0000

It's useful because it means that you can pass both unsigned and signed content using the same syntax, with no special parsing required.  This is used in practice, for instance, to enable both unsigned and signed request objects, signed and unsigned ID Tokens, etc.

Despite Richard's assertion that there is no use case for this, there's a clear use case and it's widely used in practice.

I'm also kind of surprised that this is coming up now.  This has been in JWT since March 2011 and in the JOSE specs since the working group versions, so it's not exactly a surprise.  (The biggest change was that we moved it from JWT to JWS in March 2012, at Jim Schaad's suggestion, because it is generally useful outside of just JWTs.)  Yes, an alternative syntax could have been used, but using the "alg":"none" value to express this works fine in practice.  I don't perceive a compelling reason to change it at this point.

				-- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]] 
Sent: Thursday, August 01, 2013 4:52 AM
To: jose issue tracker
Cc: <[email-masked]>; Mike Jones; <[email-masked]>; <[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

- m&m

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Aug 2013 12:11:46 +0000

That would require special parsing.  "alg":"none" doesn't.

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 5:03 AM
To: Matt Miller (mamille2)
Cc: jose issue tracker; <[email-masked]>; Mike Jones; <[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

If you really want to have a header, you could also have the unsigned JWT have 2 components (1 dot).  That way, you would demux unsigned/signed/encrypted based on number of dots, not "alg".

--Richard

On Thu, Aug 1, 2013 at 1:51 PM, Matt Miller (mamille2) <[email-masked]<mailto:[email-masked]>> wrote:
If something doesn't have a signature (or MAC, yeah yeah yeah), then I have a really hard time calling it a JWS (JSON Web Signature), and there fore have a really hard time seeing "alg":"none" as useful.

- m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >
Cisco Systems, Inc.

On Aug 1, 2013, at 1:23 PM, jose issue tracker <[email-masked]<mailto:[email-masked]>> wrote:

> Comment (by [email-masked]<mailto:[email-masked]>):
>
>  [email-masked]<mailto:[email-masked]> |  [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 14:20:06 +0200

Sure it requires special parsing.  You have to have special checking when
there's "alg":"none" to make sure there's no "kid" or "x5c", or anything
else that would hint at a downgrade attack.  It's far more complicated than:

switch (token.split(".").length) {
  case 2: process_unsigned(token); break;
  case 3: process_signed(token); break;
  case 5: process_encrypted(token); break;
  default: throw new MalformedTokenError();
}

Why are you always trying to make my code more complicated, Mike?  :)

I have sent a mail to the OAuth list suggesting a revision to the JWT spec.

--Richard

On Thu, Aug 1, 2013 at 2:11 PM, Mike Jones <[email-masked]>wrote:

>  That would require special parsing.  “alg”:”none” doesn’t.****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, August 01, 2013 5:03 AM
> *To:* Matt Miller (mamille2)
> *Cc:* jose issue tracker; <
> [email-masked]>; Mike Jones; <
> [email-masked]>
> *Subject:* Re: [jose] #36: Algorithm "none" should be removed****
>
> ** **
>
> unsigned/signed/encrypted based on number of dots, not "alg".****
>
> ** **
>
> --Richard****
>
> ** **
>
> On Thu, Aug 1, 2013 at 1:51 PM, Matt Miller (mamille2) <[email-masked]>
> wrote:****
>
> Cisco Systems, Inc.****
> >****
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Aug 2013 12:23:59 +0000

You already have to have code to verify that the "alg" value used is one that your application accepts.  You'll already reject it if it's not in your supported algorithm set.  If your application doesn't want to accept "alg":"none" the same code path that would reject "alg":"rot13" would reject "alg":"none".

I'm not making your code more complicated.  I'm sure that you already have the code to reject algorithms your application doesn't support.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 5:20 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker; <[email-masked]>; <[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

Sure it requires special parsing.  You have to have special checking when there's "alg":"none" to make sure there's no "kid" or "x5c", or anything else that would hint at a downgrade attack.  It's far more complicated than:

--Richard

On Thu, Aug 1, 2013 at 2:11 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
That would require special parsing.  "alg":"none" doesn't.

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 01, 2013 5:03 AM
To: Matt Miller (mamille2)
Cc: jose issue tracker; <[email-masked]<mailto:[email-masked]>>; Mike Jones; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [jose] #36: Algorithm "none" should be removed

--Richard

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 14:31:19 +0200

If "none" is going to be an allowed value, then presumably someone is going
to implement it.  For instance, a JWT implementation.

What is that poor implementation supposed to do?  When an attacker changes
the "alg" value to "none", the modified object passes the support check, so
the implementation pulls the right key for the "kid" value, and happily
validates.

Now I expect your argument is going to be "We provide keys out of band, so
if the implementation has gotten a key with "alg":"none", then there's an
error."  Or, "We only allow "alg":"none" over specific secure channels."
 These responses demonstrate that you require application-layer assumptions
in order for "alg":"none" to be secure.  And that means that (1) in the
spec, you need to enumerate all of those assumptions, and (2) any
implementation that supports "alg":"none" has to verify that those
assumptions are true.  And that latter thing will be impossible for a
general JOSE stack.

Are you really willing to embrace all that complexity to avoid a difference
of a single dot?

On Thu, Aug 1, 2013 at 2:23 PM, Mike Jones <[email-masked]>wrote:

>  You already have to have code to verify that the “alg” value used is one
> that your application accepts.  You’ll already reject it if it’s not in
> your supported algorithm set.  If your application doesn’t want to accept
> “alg”:”none” the same code path that would reject “alg”:”rot13” would
> reject “alg”:”none”.****
>
> ** **
>
> I’m not making your code more complicated.  I’m sure that you already have
> the code to reject algorithms your application doesn’t support.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *Sent:* Thursday, August 01, 2013 5:20 AM
> *To:* Mike Jones
> *Cc:* Matt Miller (mamille2); jose issue tracker; <
> [email-masked]>; <[email-masked]>
>
> switch (token.split(".").length) {****
>
>   case 2: process_unsigned(token); break;****
>
>   case 5: process_encrypted(token); break;****
>
>   default: throw new MalformedTokenError();****
>
> }****
>
> ** **
>
> Why are you always trying to make my code more complicated, Mike?  :)****
>
> ** **
>
> On Thu, Aug 1, 2013 at 2:11 PM, Mike Jones <[email-masked]>
> wrote:****
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Aug 2013 12:37:49 +0000

The implementation is supposed to implement whatever algorithms it does.  The *application* decides which of those algorithms meet its security requirements.  That's always been true.  That's hardly complexity - it's normal security architecture.

Just because my library implements MD2, that doesn't mean that my application should accept objects using it.  The same applies to "none" and "rot13".

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 5:31 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker; <[email-masked]>; <[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

If "none" is going to be an allowed value, then presumably someone is going to implement it.  For instance, a JWT implementation.

What is that poor implementation supposed to do?  When an attacker changes the "alg" value to "none", the modified object passes the support check, so the implementation pulls the right key for the "kid" value, and happily validates.

Now I expect your argument is going to be "We provide keys out of band, so if the implementation has gotten a key with "alg":"none", then there's an error."  Or, "We only allow "alg":"none" over specific secure channels."  These responses demonstrate that you require application-layer assumptions in order for "alg":"none" to be secure.  And that means that (1) in the spec, you need to enumerate all of those assumptions, and (2) any implementation that supports "alg":"none" has to verify that those assumptions are true.  And that latter thing will be impossible for a general JOSE stack.

Are you really willing to embrace all that complexity to avoid a difference of a single dot?

On Thu, Aug 1, 2013 at 2:23 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
You already have to have code to verify that the "alg" value used is one that your application accepts.  You'll already reject it if it's not in your supported algorithm set.  If your application doesn't want to accept "alg":"none" the same code path that would reject "alg":"rot13" would reject "alg":"none".

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 01, 2013 5:20 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>

--Richard

--Richard

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 14:52:41 +0200

Ok, I look forward to your enumerating all of the things the application
will have to check, AND demonstrating that those checks are simpler than
just using a different syntax than JWS.

On Thu, Aug 1, 2013 at 2:37 PM, Mike Jones <[email-masked]>wrote:

>  The implementation is supposed to implement whatever algorithms it
> does.  The **application** decides which of those algorithms meet its
> security requirements.  That’s always been true.  That’s hardly complexity
> – it’s normal security architecture.****
>
> ** **
>
> Just because my library implements MD2, that doesn’t mean that my
> application should accept objects using it.  The same applies to “none” and
> “rot13”.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *Sent:* Thursday, August 01, 2013 5:31 AM
>
> *To:* Mike Jones
> If "none" is going to be an allowed value, then presumably someone is
> going to implement it.  For instance, a JWT implementation.****
>
> ** **
>
> validates.****
> general JOSE stack.****
> Are you really willing to embrace all that complexity to avoid a
> difference of a single dot?****
>
> ** **
>
> ** **
>
> On Thu, Aug 1, 2013 at 2:23 PM, Mike Jones <[email-masked]>
> wrote:****
>
> [email-masked]>; <[email-masked]>****
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Aug 2013 13:04:12 +0000

Applications always have to make a security decision about whether an algorithm is acceptable in its context or not.

It makes no security difference whether non-integrity-protected text is passed using "alg":"none" or passed using a different syntax.  It's still the responsibility of the application, in context, to decide whether to reject that input or not.

If "none" isn't in the algorithm's acceptable set of algorithms for that application context, then a downgrade attack is no more possible to "none" than a downgrade attack would be possible to "rot13", unless the application explicitly chose to accept it.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 5:53 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker; <[email-masked]>; <[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

Ok, I look forward to your enumerating all of the things the application will have to check, AND demonstrating that those checks are simpler than just using a different syntax than JWS.

On Thu, Aug 1, 2013 at 2:37 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The implementation is supposed to implement whatever algorithms it does.  The *application* decides which of those algorithms meet its security requirements.  That's always been true.  That's hardly complexity - it's normal security architecture.

                                                            -- Mike

To: Mike Jones

                                                            -- Mike

--Richard

--Richard

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 17:06:07 +0200

Please describe the circumstances under which "alg":"none" is acceptable.

Keep in mind that pretty much every application protocol outlaws the use of
the TLS null ciphersuites.

On Thu, Aug 1, 2013 at 3:04 PM, Mike Jones <[email-masked]>wrote:

>  Applications always have to make a security decision about whether an
> algorithm is acceptable in its context or not.****
>
> ** **
>
> It makes no security difference whether non-integrity-protected text is
> passed using “alg”:”none” or passed using a different syntax.  It’s still
> the responsibility of the application, in context, to decide whether to
> reject that input or not.****
>
> ** **
>
> If “none” isn’t in the algorithm’s acceptable set of algorithms for that
> application context, then a downgrade attack is no more possible to “none”
> than a downgrade attack would be possible to “rot13”, unless the
> application explicitly chose to accept it.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *Sent:* Thursday, August 01, 2013 5:53 AM
>
> *To:* Mike Jones
> just using a different syntax than JWS.****
>
> ** **
>
> On Thu, Aug 1, 2013 at 2:37 PM, Mike Jones <[email-masked]>
> wrote:****
>
> The implementation is supposed to implement whatever algorithms it does.
> The **application** decides which of those algorithms meet its security
> requirements.  That’s always been true.  That’s hardly complexity – it’s
> normal security architecture.****
>
>  ****
>
> *Sent:* Thursday, August 01, 2013 5:31 AM****
>
>
> *To:* Mike Jones

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Aug 2013 01:39:03 +1000

Supporting unprotected JOSE messages is a useful option.

Pretending an unprotected message is a subclass of a signed message is the problem. It is a cute, but unnecessary, hack. It encourages libraries and APIs to hide the *crucial* distinction between unprotected and signed messages (eg by represented both with a single JWS class).

An unprotected JOSE message needs to be a distinct type (distinct from JWE and JWS) that consists of a header and payload (no extra dot or empty signature field).

We should not distinguish some classes of JOSE message by dot-count, others looking up the "alg" value in a table, and others by the presence or absence of "enc". We need one mechanism. We desperately need a proper type field, but without that we can try to fudge our way through by overloading the "alg" field.

"alg":"none" can identify an unprotected JOSE message.

Unprotected JOSE messages need to be defined in JOSE, not JWT.

The organization of JOSE specs is causing real grief due to the lack of the concept of a JOSE message. Instead we only have JWS and JWE messages. A lot of text is duplicated between JWS and JWE; a lots of text is similar-but-not-quite-identical between JWS and JWE. Things have to be contorted to fit JWS or JWE: Unprotected messages treated as signed; MACs and asymmetric signatures treated as the same; symmetric key establishment working for symmetric encryption but not for symmetric MACs...

> Applications always have to make a security decision about whether an algorithm is acceptable in its context or not.

Deciding if, say, SHA-1 or SHA-256 is acceptable is very different than deciding if signed, encrypted, or unprotected is acceptable. Theoretically, apps make both choices, but in practice the former is often left to the library or O/S. The former should be a matter of configuring a list of strings; the latter requires explicit code support.

Minimal suggestion:
Add a new section to the JWS spec (eg 7. Unprotected message); consists of header and payload; header contains "alg":"none".

Sensible suggestion:
A JOSE spec; a proper type field; separate sections for unprotected messages, MAC messages, and asymmetrically-signed messages; could leave the encryption (and key exchange) message in a separate spec.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 17:42:24 +0200

James,

Could you say what you mean by an "unprotected JOSE message"?  A JOSE
message is nothing more than (1) content, and (2) crypto processing
instructions.  If you're not doing any crypto, you're left with the
content, so why do you need the JOSE wrapper?

--Richard

On Thu, Aug 1, 2013 at 5:39 PM, Manger, James H <
[email-masked]> wrote:

> Pretending an unprotected message is a subclass of a signed message is the
> problem. It is a cute, but unnecessary, hack. It encourages libraries and
> APIs to hide the *crucial* distinction between unprotected and signed
> messages (eg by represented both with a single JWS class).
>
> An unprotected JOSE message needs to be a distinct type (distinct from JWE
> and JWS) that consists of a header and payload (no extra dot or empty
> signature field).
>
> We should not distinguish some classes of JOSE message by dot-count,
> others looking up the "alg" value in a table, and others by the presence or
> absence of "enc". We need one mechanism. We desperately need a proper type
> field, but without that we can try to fudge our way through by overloading
> the "alg" field.
>
> The organization of JOSE specs is causing real grief due to the lack of
> the concept of a JOSE message. Instead we only have JWS and JWE messages. A
> lot of text is duplicated between JWS and JWE; a lots of text is
> similar-but-not-quite-identical between JWS and JWE. Things have to be
> contorted to fit JWS or JWE: Unprotected messages treated as signed; MACs
> and asymmetric signatures treated as the same; symmetric key establishment
> working for symmetric encryption but not for symmetric MACs...
>
>
> algorithm is acceptable in its context or not.
>
> Deciding if, say, SHA-1 or SHA-256 is acceptable is very different than
> deciding if signed, encrypted, or unprotected is acceptable. Theoretically,
> apps make both choices, but in practice the former is often left to the
> library or O/S. The former should be a matter of configuring a list of
> strings; the latter requires explicit code support.
>
>
> Minimal suggestion:
> Add a new section to the JWS spec (eg 7. Unprotected message); consists of
> header and payload; header contains "alg":"none".
>
> Sensible suggestion:
> A JOSE spec; a proper type field; separate sections for unprotected
> messages, MAC messages, and asymmetrically-signed messages; could leave the
> encryption (and key exchange) message in a separate spec.
>
> --
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Aug 2013 02:04:38 +1000

> James,
> 
> Could you say what you mean by an "unprotected JOSE message"?

A JOSE message that offers no cryptographic protection to its payload.

>  A JOSE

To distinguish content from content+crypto.

If a field in a protocol usually needs integrity, authenticity, or confidentiality protection, but in some circumstances those protections are unnecessary (eg they come from a lower layer), then the protocol should define its value to be a JOSE message. You need to be able to indicate whether a given field value is content+crypto or content.

You cannot define the field as holding: a JOSE message (compact serialization), or raw string content. Because the raw content might look like a JOSE message!

--
James Manger

> 
> --Richard
> 
> On Thu, Aug 1, 2013 at 5:39 PM, Manger, James H
> <[email-masked]> wrote:
> Pretending an unprotected message is a subclass of a signed message is
> the problem. It is a cute, but unnecessary, hack. It encourages
> libraries and APIs to hide the *crucial* distinction between
> unprotected and signed messages (eg by represented both with a single
> JWS class).
> 
> An unprotected JOSE message needs to be a distinct type (distinct from
> JWE and JWS) that consists of a header and payload (no extra dot or
> empty signature field).
> 
> others looking up the "alg" value in a table, and others by the
> presence or absence of "enc". We need one mechanism. We desperately
> need a proper type field, but without that we can try to fudge our way
> through by overloading the "alg" field.
> 
> the concept of a JOSE message. Instead we only have JWS and JWE
> messages. A lot of text is duplicated between JWS and JWE; a lots of
> text is similar-but-not-quite-identical between JWS and JWE. Things
> have to be contorted to fit JWS or JWE: Unprotected messages treated as
> signed; MACs and asymmetric signatures treated as the same; symmetric
> key establishment working for symmetric encryption but not for
> symmetric MACs...
> 
> 
> deciding if signed, encrypted, or unprotected is acceptable.
> Theoretically, apps make both choices, but in practice the former is
> often left to the library or O/S. The former should be a matter of
> configuring a list of strings; the latter requires explicit code
> support.
> 
> 
> Minimal suggestion:
> Add a new section to the JWS spec (eg 7. Unprotected message); consists
> of header and payload; header contains "alg":"none".
> 
> Sensible suggestion:
> messages, MAC messages, and asymmetrically-signed messages; could leave
> the encryption (and key exchange) message in a separate spec.
> 
> --
> James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 18:15:20 +0200

On Thu, Aug 1, 2013 at 6:04 PM, Manger, James H <
[email-masked]> wrote:

> If a field in a protocol usually needs integrity, authenticity, or
> confidentiality protection, but in some circumstances those protections are
> unnecessary (eg they come from a lower layer), then the protocol should
> define its value to be a JOSE message. You need to be able to indicate
> whether a given field value is content+crypto or content.
>
> You cannot define the field as holding: a JOSE message (compact
> serialization), or raw string content. Because the raw content might look
> like a JOSE message!
>

If you base64 the content, it will never look like JOSE.  It won't look
like a compact JOSE object, since it's a base64 string with the wrong
number of components (1 instead of 3/5).  It won't look like a JSON JOSE
object, because it won't be JSON.

So, I actually proposed some syntax on this on the OAuth list.  The
proposal allows a header, but the concept is the same.
<http://www.ietf.org/mail-archive/web/oauth/current/msg11857.html>

The important thing here is that however the unprotected stuff is
represented, it must have the property that if I feed it into a JOSE
library, the library will say "This is not a JWS or JWE", not "This is a
valid JWS".

--Richard

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Aug 2013 10:10:29 +1000

>> serialization), or raw string content. Because the raw content might
>> look like a JOSE message!

> number of components (1 instead of 3/5).  It won't look like a JSON
> JOSE object, because it won't be JSON.
>

I like that proposal. It should be in a JOSE doc, not JWT.

Either "alg":"none" or "alg" being absent could be used to distinguish the unprotect message from JWEs and JWSs. "alg":"none" is more consistent with:
  "alg":"RS256"   -> asym-JWS,
  "alg":"HS256"   -> sym-JWS,
  "alg":"dir"     -> sym-JWE,
  "alg":"ECDH-ES" -> asym-key-agree-JWE,
  "alg":"A128KW"  -> sym-key-wrap-JWE

"T":"none" would be better.

> library, the library will say "This is not a JWS or JWE", not "This is
> a valid JWS".

Agree.
Unprotected stuff should have 2 segments (header.payload), which encourages implementers not to treat it as a special case of JWS.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Aug 2013 08:49:05 +0200

Great.  Glad there's some agreement here.

One other minor thing: We shouldn't call this thing "JWS", but maybe
"JWContent" or something.

On Fri, Aug 2, 2013 at 2:10 AM, Manger, James H <
[email-masked]> wrote:

> Either "alg":"none" or "alg" being absent could be used to distinguish the
> unprotect message from JWEs and JWSs. "alg":"none" is more consistent with:
> Unprotected stuff should have 2 segments (header.payload), which
> encourages implementers not to treat it as a special case of JWS.
>
> --
> James Manger
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 12:30:14 -0400

I don't normally jump into the discussion on this list, but I've been 
using the output of JOSE for quite some time now and am a committer on 
the NimbusDS JOSE JWT library. However, with tonight's call coming up 
(which I won't be able to make) I wanted to jump in and say that from my 
perspective, alg:none makes a lot of sense. There's a need for being 
able to send unsigned content with JOSE objects, and that's been pretty 
well established by others on the list here. As an implementor, though, 
I think it makes the most sense to have the unsigned content be parallel 
in structure to the signed content. When reading a string and 
constructing objects, our library parses the header and dispatches the 
parser based on the "alg" parameter.

And as Mike points out, alg:none has been in the spec as required to 
implement for ages now, and it hasn't caused the horrible security holes 
that people are predicting.

  -- Justin

---

From: George Fletcher <[email-masked]>
Date: Mon, 19 Aug 2013 13:17:06 -0400

+1 "for being able to send unsigned content with JOSE objects" using a 
structure that is parallel to signed content

I find symmetric models much less complex than asymmetric ones (maybe 
I'm missing the symmetry of the other model).

In practice, most systems are only going to support a subset of the alg: 
values anyway and so will have to check the value on every object to 
ensure it's one of the ones supported for that library, or message, etc. 
Filtering out 'none' is not difficult.

Thanks,
George

On 8/19/13 12:30 PM, Justin Richer wrote:
> (which I won't be able to make) I wanted to jump in and say that from 
> my perspective, alg:none makes a lot of sense. There's a need for 
> being able to send unsigned content with JOSE objects, and that's been 
> pretty well established by others on the list here. As an implementor, 
> though, I think it makes the most sense to have the unsigned content 
> be parallel in structure to the signed content. When reading a string 
> and constructing objects, our library parses the header and dispatches 
> the parser based on the "alg" parameter.
>
> implement for ages now, and it hasn't caused the horrible security 
> holes that people are predicting.
>
>  -- Justin
>

-- 
<http://connect.me/gffletch>

---

From: Edmund Jay <[email-masked]>
Date: Mon, 19 Aug 2013 10:36:52 -0700 (PDT)

I agree with keeping support for alg:none. There is a need for unsigned objects and it's better that the underlying specs allow such functionality and leave it up to the higher up application layers to determine which subset is supported.

________________________________
 From: George Fletcher <[email-masked]>
To: Justin Richer <[email-masked]> 
Cc: [email-masked]; [email-masked]; jose issue tracker <[email-masked]>; [email-masked]; [email-masked] 
Sent: Monday, August 19, 2013 10:17 AM
Subject: Re: [jose] #36: Algorithm "none" should be removed

+1 "for being able to send unsigned content with JOSE objects" using a structure that is parallel to signed content

I find symmetric models much less complex than asymmetric ones
      (maybe I'm missing the symmetry of the other model).

In practice, most systems are only going to support a subset of
      the alg: values anyway and so will have to check the value on
      every object to ensure it's one of the ones supported for that
      library, or message, etc. Filtering out 'none' is not difficult.

Thanks,
George

I don't normally jump into the discussion on this list, but I've been using the output of JOSE for quite some time now and am a committer on the NimbusDS JOSE JWT library. However, with tonight's call coming up (which I won't be able to make) I wanted to jump in and say that from my perspective, alg:none makes a lot of sense. There's a need for being able to send unsigned content with JOSE objects, and that's been pretty well established by others on the list here. As an implementor, though, I think it makes the most sense to have the unsigned content be parallel in structure to the signed content. When reading a string and constructing objects, our library parses the header and dispatches the parser based on the "alg" parameter. 
>
>And as Mike points out, alg:none has been in the spec as required
      to implement for ages now, and it hasn't caused the horrible
      security holes that people are predicting. 

--

---

From: <[email-masked]>
Date: Mon, 19 Aug 2013 19:59:05 +0200

+1 keep "none"

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Monday, August 19, 2013 7:17 PM
To: Justin Richer
Cc: [email-masked]; [email-masked]; jose issue tracker; [email-masked]; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

I find symmetric models much less complex than asymmetric ones (maybe I'm missing the symmetry of the other model).

In practice, most systems are only going to support a subset of the alg: values anyway and so will have to check the value on every object to ensure it's one of the ones supported for that library, or message, etc. Filtering out 'none' is not difficult.

Thanks,
George

And as Mike points out, alg:none has been in the spec as required to implement for ages now, and it hasn't caused the horrible security holes that people are predicting.

 -- Justin

--

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 12:14:14 -0700

From a consistency perspective:

a.  There are those that see everything as JWT tokens so a signature=none makes perfect sense for consistency
b.  There are those that see everything as JSON.  JWT is seen as the edge case. Consistency means keeping things in plain old JSON.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 15:22:26 -0400

For both of these cases, wouldn't having alg:none in the header be the 
only way to be consistent with unsigned content across both the compact 
format and the JSON-based format? Or am I missing something?

  -- Justin

On 08/19/2013 03:14 PM, Phil Hunt wrote:
> a.  There are those that see everything as JWT tokens so a 
> signature=none makes perfect sense for consistency
> b.  There are those that see everything as JSON.  JWT is seen as the 
> edge case. Consistency means keeping things in plain old JSON.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
> On 2013-08-19, at 10:17 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> +1 "for being able to send unsigned content with JOSE objects" using 
>> a structure that is parallel to signed content
>>
>> In practice, most systems are only going to support a subset of the 
>> alg: values anyway and so will have to check the value on every 
>> object to ensure it's one of the ones supported for that library, or 
>> message, etc. Filtering out 'none' is not difficult.
>>
>> Thanks,
>> George
>>
>>> I don't normally jump into the discussion on this list, but I've 
>>> been using the output of JOSE for quite some time now and am a 
>>> committer on the NimbusDS JOSE JWT library. However, with tonight's 
>>> call coming up (which I won't be able to make) I wanted to jump in 
>>> and say that from my perspective, alg:none makes a lot of sense. 
>>> There's a need for being able to send unsigned content with JOSE 
>>> objects, and that's been pretty well established by others on the 
>>> list here. As an implementor, though, I think it makes the most 
>>> sense to have the unsigned content be parallel in structure to the 
>>> signed content. When reading a string and constructing objects, our 
>>> library parses the header and dispatches the parser based on the 
>>> "alg" parameter.
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Mon, 19 Aug 2013 15:48:56 -0400

In OAuth and Connect there are cases where you are receiving tokens from multiple sources.  By allowing none as a alg option we can process signed or unsigned tokens with the same basic handler by inspecting the first segment.  I note currently that while none has three segments the last segment must be empty.   I think that is sufficient to keep people from becoming confused.

Making it two segments will break existing parsers for no good reason.

What we call it I am flexible about, if it is a unsigned JOSE object in compact serialization i am fine.

John B.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:17:54 -0400

On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[email-masked]> wrote:

> In OAuth and Connect there are cases where you are receiving tokens from
> multiple sources.  By allowing none as a alg option we can process signed
> or unsigned tokens with the same basic handler by inspecting the first
> segment.  I note currently that while none has three segments the last
> segment must be empty.   I think that is sufficient to keep people from
> becoming confused.
>

No, there's a very good reason.  Something that is not signed should not be
accepted as a JSON Web Signature object.  Acceptance of a JWS implies that
the payload and protected headers were integrity protected from the signer;
that is not true for "alg":"none".

Also, it's not clear that this change will break existing parsers.  For
example, the NimbusDS parser would successfully parse a two-segment object
as a "plain JWT"
<
https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master

What we call it I am flexible about, if it is a unsigned JOSE object in
> compact serialization i am fine.
>

I would also be completely fine with an unsigned "header + content"
structure (though I don't think it adds any value).  But it must be
recognizably different from JWS.

--Richard, who is honestly kind of floored that there's all this argument
over a single "." character

> using the output of JOSE for quite some time now and am a committer on the
> NimbusDS JOSE JWT library. However, with tonight's call coming up (which I
> won't be able to make) I wanted to jump in and say that from my
> perspective, alg:none makes a lot of sense. There's a need for being able
> to send unsigned content with JOSE objects, and that's been pretty well
> established by others on the list here. As an implementor, though, I think
> it makes the most sense to have the unsigned content be parallel in
> structure to the signed content. When reading a string and constructing
> objects, our library parses the header and dispatches the parser based on
> the "alg" parameter.
> >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:21:02 -0400

But that signature is valid for that algorithm.  So a generic JWS parser
will show it as accepted.

On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <[email-masked]>wrote:

>  Having an empty signature segment already makes it recognizably
> different.****
>
> ** **
>
> *Sent:* Monday, August 19, 2013 1:18 PM
> *To:* John Bradley
> *Cc:* Justin Richer; jose issue tracker; Mike Jones; [email-masked];
> [email-masked]
> On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[email-masked]> wrote:**
> **
>
> Making it two segments will break existing parsers for no good reason.****
>
>  ** **
>
> No, there's a very good reason.  Something that is not signed should not
> be accepted as a JSON Web Signature object.  Acceptance of a JWS implies
> that the payload and protected headers were integrity protected from the
> signer; that is not true for "alg":"none".  ****
>
> ** **
>
> as a "plain JWT"****
> compact serialization i am fine.****
>
>  ** **
>
> recognizably different from JWS.****
>
> ** **
>
> over a single "." character****
>
> ** **
>
> ** **
>
> ** **
>
>  ****
>
>
> John B.****
>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Aug 2013 20:23:16 +0000

It is accepted.  That doesn't mean that the application should accept it unless it validates that the actual algorithm used meets its security requirements, whether it's "none", or not.  (For instance, if you require HS512 or ES512, your application will need to reject inputs that used HS256, etc.)  This is a basic requirement for secure applications - not a new requirement created by the presence of "none".

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, August 19, 2013 1:21 PM
To: Mike Jones
Cc: John Bradley; Justin Richer; jose issue tracker; [email-masked]; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

But that signature is valid for that algorithm.  So a generic JWS parser will show it as accepted.

On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Having an empty signature segment already makes it recognizably different.

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 19, 2013 1:18 PM
To: John Bradley
Cc: Justin Richer; jose issue tracker; Mike Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
In OAuth and Connect there are cases where you are receiving tokens from multiple sources.  By allowing none as a alg option we can process signed or unsigned tokens with the same basic handler by inspecting the first segment.  I note currently that while none has three segments the last segment must be empty.   I think that is sufficient to keep people from becoming confused.

No, there's a very good reason.  Something that is not signed should not be accepted as a JSON Web Signature object.  Acceptance of a JWS implies that the payload and protected headers were integrity protected from the signer; that is not true for "alg":"none".

Also, it's not clear that this change will break existing parsers.  For example, the NimbusDS parser would successfully parse a two-segment object as a "plain JWT"
<https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master>

I would also be completely fine with an unsigned "header + content" structure (though I don't think it adds any value).  But it must be recognizably different from JWS.

--Richard, who is honestly kind of floored that there's all this argument over a single "." character

John B.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 19 Aug 2013 20:28:14 +0000

> over a single "." character

I completely agree with Richard.

- m&m

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 13:29:06 -0700

I think it is dangerous to say signature is valid if alg:none.  Richard is right. The app will get a binary response and will assume there was a signature.

Why not simply detect if "alg":"somealg" is present and if not, proceed direct to payload processing?

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-19, at 1:23 PM, Mike Jones <[email-masked]> wrote:

> It is accepted.  That doesn’t mean that the application should accept it unless it validates that the actual algorithm used meets its security requirements, whether it’s “none”, or not.  (For instance, if you require HS512 or ES512, your application will need to reject inputs that used HS256, etc.)  This is a basic requirement for secure applications – not a new requirement created by the presence of “none”.
>  
>                                                                 -- Mike
>  
> On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <[email-masked]> wrote:
> Cc: Justin Richer; jose issue tracker; Mike Jones; [email-masked]; [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Aug 2013 20:30:35 +0000

Because it breaks the invariant that you use the "alg" parameter value to determine how to process the JOSE object.

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, August 19, 2013 1:29 PM
To: Mike Jones
Cc: Richard Barnes; John Bradley; jose issue tracker; Justin Richer; [email-masked]; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-08-19, at 1:23 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, August 19, 2013 1:21 PM
To: Mike Jones
Cc: John Bradley; Justin Richer; jose issue tracker; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

John B.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:32:11 -0400

Since we've been here before, let me just include my rebuttal by reference
<http://www.ietf.org/mail-archive/web/jose/current/msg02952.html>

On Mon, Aug 19, 2013 at 4:23 PM, Mike Jones <[email-masked]>wrote:

>  It is accepted.  That doesn’t mean that the application should accept it
> unless it validates that the actual algorithm used meets its security
> requirements, whether it’s “none”, or not.  (For instance, if you require
> HS512 or ES512, your application will need to reject inputs that used
> HS256, etc.)  This is a basic requirement for secure applications – not a
> new requirement created by the presence of “none”.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *Sent:* Monday, August 19, 2013 1:21 PM
> *To:* Mike Jones
> *Cc:* John Bradley; Justin Richer; jose issue tracker; [email-masked];
> will show it as accepted.****
>
> ** **
>
> On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <[email-masked]>
> wrote:****
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Aug 2013 20:18:14 +0000

John B.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:34:49 -0400

Too bad that "invariant" is already broken by the existence of the JSON
serialization, etc.  You can't even find the header unless you know whether
you're looking at JSON or compact, and if JSON, JWS or JWE.  Heck, in a
multi-recipient JWE, there's not even an "alg" parameter at the top level.

On Mon, Aug 19, 2013 at 4:30 PM, Mike Jones <[email-masked]>wrote:

>  Because it breaks the invariant that you use the “alg” parameter value
> to determine how to process the JOSE object.****
>
> ** **
>
> *From:* Phil Hunt [mailto:[email-masked]]
> *Sent:* Monday, August 19, 2013 1:29 PM
> *To:* Mike Jones
> *Cc:* Richard Barnes; John Bradley; jose issue tracker; Justin Richer;
> [email-masked]; [email-masked]
>
> I think it is dangerous to say signature is valid if alg:none.  Richard is
> right. The app will get a binary response and will assume there was a
> signature.****
>
> ** **
>
> Why not simply detect if "alg":"somealg" is present and if not, proceed
> direct to payload processing?****
>
> ** **
>
> Phil****
>
> ** **
>
> @independentid****
>
> www.independentid.com****
>
> [email-masked]****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 19 Aug 2013 21:04:59 +0000

As I think Richard has pointed out previously, we've got much better (and cheaper) detection schemes than the "alg" property:

* compact: 2 dots == JWS, 4 dots == JWE (else !JOSE)
* JSON: "signatures" == JWS, "ciphertext" == JWE (else !JOSE)

Counting dots in the compact serialization requires significantly less effort than decoding then parsing then analyzing the header. Checking for property existence in the JSON (de) serialization also requires (arguably significantly) less effort than merging the various headers (one with an additional base64url decode step) in the appropriate manner.

It's boggling to me that so many accept a ready-made (REQUIRED!) exploit because it's incompatible with existing implementations.  We've broken compatibility in the past for good reasons, and this seems like an awfully good reason to do the same.

- m&m

On Aug 19, 2013, at 2:30 PM, Mike Jones <[email-masked]> wrote:

> Because it breaks the invariant that you use the “alg” parameter value to determine how to process the JOSE object.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Aug 2013 14:06:44 -0700

What happens when I give you a new alg parameter value because I have
defined a new algorithm?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Monday, August 19, 2013 1:31 PM
To: Phil Hunt
Cc: Richard Barnes; jose issue tracker; [email-masked]; John Bradley; Justin
Richer; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

Because it breaks the invariant that you use the "alg" parameter value to
determine how to process the JOSE object.

Cc: Richard Barnes; John Bradley; jose issue tracker; Justin Richer;

signature.

Why not simply detect if "alg":"somealg" is present and if not, proceed
direct to payload processing?

Phil

@independentid

www.independentid.com

[email-masked]

 

It is accepted.  That doesn't mean that the application should accept it
unless it validates that the actual algorithm used meets its security
requirements, whether it's "none", or not.  (For instance, if you require
HS512 or ES512, your application will need to reject inputs that used HS256,
etc.)  This is a basic requirement for secure applications - not a new
requirement created by the presence of "none".

                                                                -- Mike

Cc: John Bradley; Justin Richer; jose issue tracker; [email-masked];

On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <
<mailto:[email-masked]> [email-masked]> wrote:

From: Richard Barnes [mailto: <mailto:[email-masked]> [email-masked]] 
Sent: Monday, August 19, 2013 1:18 PM
To: John Bradley
Cc: Justin Richer; jose issue tracker; Mike Jones;  <mailto:[email-masked]>
[email-masked];  <mailto:[email-masked]>
[email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

On Mon, Aug 19, 2013 at 3:48 PM, John Bradley < <mailto:[email-masked]>
[email-masked]> wrote:

In OAuth and Connect there are cases where you are receiving tokens from
multiple sources.  By allowing none as a alg option we can process signed or
unsigned tokens with the same basic handler by inspecting the first segment.
I note currently that while none has three segments the last segment must be
empty.   I think that is sufficient to keep people from becoming confused.

<
<https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583
dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master>
https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583d
ffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master>

 

John B.

using the output of JOSE for quite some time now and am a committer on the
NimbusDS JOSE JWT library. However, with tonight's call coming up (which I
won't be able to make) I wanted to jump in and say that from my perspective,
alg:none makes a lot of sense. There's a need for being able to send
unsigned content with JOSE objects, and that's been pretty well established
by others on the list here. As an implementor, though, I think it makes the
most sense to have the unsigned content be parallel in structure to the
signed content. When reading a string and constructing objects, our library
parses the header and dispatches the parser based on the "alg" parameter.
>> Comment (by  <mailto:[email-masked]> [email-masked]):
>>

>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/jose>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 17:09:17 -0400

So, once I've figured out what serialization I'm in and whether I'm in a
JWE or JWS, I can use "alg" to determine whether I'm in a JWE or JWS.
 Handy!

I would also point out that Phil's suggestion *doesn't* break this
invariant, since you would interpret "alg":"none" to do no further
processing.

On Mon, Aug 19, 2013 at 4:38 PM, Mike Jones <[email-masked]>wrote:

>  It still holds.  Once you determine the Header Parameter values (a
> process that is admittedly serialization-specific), you use the “alg” value
> in all cases to determine what operations to perform for that recipient.**
> **
>
> ** **
>
> *Sent:* Monday, August 19, 2013 1:35 PM
> *To:* Mike Jones
> *Cc:* Phil Hunt; John Bradley; jose issue tracker; Justin Richer;
> On Mon, Aug 19, 2013 at 4:30 PM, Mike Jones <[email-masked]>
> wrote:****
>
> Because it breaks the invariant that you use the “alg” parameter value to
> determine how to process the JOSE object.****
>
>  ****
>
> [email-masked]; [email-masked]****
>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Aug 2013 20:38:31 +0000

It still holds.  Once you determine the Header Parameter values (a process that is admittedly serialization-specific), you use the "alg" value in all cases to determine what operations to perform for that recipient.

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, August 19, 2013 1:35 PM
To: Mike Jones
Cc: Phil Hunt; John Bradley; jose issue tracker; Justin Richer; [email-masked]; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

Too bad that "invariant" is already broken by the existence of the JSON serialization, etc.  You can't even find the header unless you know whether you're looking at JSON or compact, and if JSON, JWS or JWE.  Heck, in a multi-recipient JWE, there's not even an "alg" parameter at the top level.

On Mon, Aug 19, 2013 at 4:30 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Because it breaks the invariant that you use the "alg" parameter value to determine how to process the JOSE object.

From: Phil Hunt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 19, 2013 1:29 PM
To: Mike Jones
Cc: Richard Barnes; John Bradley; jose issue tracker; Justin Richer; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Phil

@independentid

                                                                -- Mike

John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Aug 2013 14:10:04 -0700

John,

In these cases are you carrying information in the JWS object other than the
algorithm?  I am trying to figure out if the "protected header" field is
really used in this case.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Bradley
> Sent: Monday, August 19, 2013 12:49 PM
> To: Justin Richer
> Cc: [email-masked]; [email-masked]; jose issue tracker;
or
> unsigned tokens with the same basic handler by inspecting the first
compact
> serialization i am fine.
using
> the output of JOSE for quite some time now and am a committer on the
to
> send unsigned content with JOSE objects, and that's been pretty well
it
> makes the most sense to have the unsigned content be parallel in structure
> to the signed content. When reading a string and constructing objects, our
> library parses the header and dispatches the parser based on the "alg"
> parameter.
> >
> >>  And sure enough, working groups across the IETF are having to
> >> explicitly  forbid the use of null ciphersuites.  They provide
> >> empirical evidence that  this design pattern is a bad idea.
> >>
> >>  As I've pointed out before, you can add that verification algorithm,
> >> but  you will not have a good time writing security considerations
around
> it.
> >>  *nothing* *else* in the header could possibly indicate that a
> >> different  signature algorithm should be used.
> >>
> >> security vulnerabilities under likely implementaiton designs, and (3)
> >> has  no use case, and (4) will haunt us for years to come (how many
> >> times do  you want to write 'MUST NOT use "alg":"none"'?).  Sounds
> >> like a recipe for  success!
> >>
> >

---

From: John Bradley <[email-masked]>
Date: Mon, 19 Aug 2013 17:11:06 -0400

If the receiver doesn't recognize the new alg parameter it must throw an error.

I can't imagine processing and returning success with an unknown parameter value.

On 2013-08-19, at 5:06 PM, "Jim Schaad" <[email-masked]> wrote:

> What happens when I give you a new alg parameter value because I have defined a new algorithm?
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
> Cc: Richard Barnes; jose issue tracker; [email-masked]; John Bradley; Justin Richer; [email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 19 Aug 2013 17:20:22 -0400

Yes information like issuer may be present in the header as is allowed by JWT.   

In one case the body is a binary blob and all the information iss aud etc are in the header.  The same payload may also be sent signed to allow the receiver to verify the object before it is sent off for introspection to avoid denial of service attacks on the introspection endpoint. 

So the receiver may or may not allow alg none based on the iss.

In the common case of the openID request object the client specifies during registration what algorithm must be used to validate it's requests.   
Some clients want to use the JSON request format but don't care about integrity protecting the request, others doing higher LOA may need to sign or encrypt requests for non repudiation and privacy.
In Connect currently the format of the request is the same in that it is a JWT that can be signed unsigned or encrypted.

John B.

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 17:27:23 -0400

On 08/19/2013 04:17 PM, Richard Barnes wrote:
>     In OAuth and Connect there are cases where you are receiving
>     tokens from multiple sources.  By allowing none as a alg option we
>     can process signed or unsigned tokens with the same basic handler
>     by inspecting the first segment.  I note currently that while none
>     has three segments the last segment must be empty.   I think that
>     is sufficient to keep people from becoming confused.
>
> No, there's a very good reason.  Something that is not signed should 
> not be accepted as a JSON Web Signature object.  Acceptance of a JWS 
> implies that the payload and protected headers were integrity 
> protected from the signer; that is not true for "alg":"none".
>
> Also, it's not clear that this change will break existing parsers. 
>  For example, the NimbusDS parser would successfully parse a 
> two-segment object as a "plain JWT"

Uh, no, it doesn't. In fact, it throws an error:

    java.text.ParseException: Invalid serialized plain/JWS/JWE object:
    Missing second delimiter
         at com.nimbusds.jose.JOSEObject.split(JOSEObject.java:222)
         at com.nimbusds.jwt.PlainJWT.parse(PlainJWT.java:99)
         at com.nimbusds.jwt.JWTParser.parse(JWTParser.java:61)

 From that very code you should be able to see that it plucks off the 
header and looks for the algorithm value, creating a "PlainJWT" object 
if alg=none.

>
>
>     What we call it I am flexible about, if it is a unsigned JOSE
>     object in compact serialization i am fine.
>
>

I am too, but from the opposite end -- why is it so important for you to 
delete that single "." character?

  -- Justin

>     committer on the NimbusDS JOSE JWT library. However, with
>     tonight's call coming up (which I won't be able to make) I wanted
>     to jump in and say that from my perspective, alg:none makes a lot
>     of sense. There's a need for being able to send unsigned content
>     with JOSE objects, and that's been pretty well established by
>     others on the list here. As an implementor, though, I think it
>     makes the most sense to have the unsigned content be parallel in
>     structure to the signed content. When reading a string and
>     constructing objects, our library parses the header and dispatches
>     > And as Mike points out, alg:none has been in the spec as
>     required to implement for ages now, and it hasn't caused the
>     horrible security holes that people are predicting.
>     >
>     > -- Justin
>     >
>     explicitly

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 17:46:57 -0400

On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[email-masked]> wrote:

> signer; that is not true for "alg":"none".
>
> java.text.ParseException: Invalid serialized plain/JWS/JWE object: Missing
> second delimiter
> header and looks for the algorithm value, creating a "PlainJWT" object if
> alg=none.
>

Ah, the risks of reading code.  I stand corrected.  At least the top-level
parsing works, so you could just adapt the PlainJWT.parse() method.

> delete that single "." character?

It's important that something that is not signed is does not pass JWS
validation.  If something unsigned is ever accepted as a valid JWS, then
there's a huge downgrade risk.

--Richard

>> but
>> has

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Aug 2013 15:32:34 -0700

Do you consider the people who are implementing the JWT specification to be
novice or expert cryptography users?  The problem is much more likely to
occur with novice users of the system.  The problem is also much more likely
to occur after it is out in the real world and is protecting real and
valuable assets than when it is just starting out.  After all DNS had no
real problems for the first umpteen years before people decided that
attacking DNS was a worthwhile endeavor.

Jim

> Justin Richer
> Sent: Monday, August 19, 2013 9:30 AM
> To: jose issue tracker
> Cc: [email-masked]; [email-masked]; [email-masked];
draft-ietf-jose-
> [email-masked]
using the
> output of JOSE for quite some time now and am a committer on the
to
it
explicitly
but
> >   *nothing* *else* in the header could possibly indicate that a
different
has

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 21:39:18 -0400

On the call today, I was asked to generate a proposal for what it would
look like to support a "header+payload" format that was not JWS.  I have
attached a patch to JWS and JWA to ISSUE-36

tl;dr: Define JSON Web Payload, which is JWS without a signature and MUST
NOT be accepted by verify()

<http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch

On Mon, Aug 19, 2013 at 6:32 PM, Jim Schaad <[email-masked]> wrote:

> structure
> > >   you want to write 'MUST NOT use "alg":"none"'?).  Sounds like a
> recipe
> > for
> > >   success!
> > >
> >

---

From: Justin Richer <[email-masked]>
Date: Tue, 20 Aug 2013 09:49:53 -0400

On 08/19/2013 05:46 PM, Richard Barnes wrote:
>
>
>
> On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>         tokens from multiple sources.  By allowing none as a alg
>>         option we can process signed or unsigned tokens with the same
>>         basic handler by inspecting the first segment.  I note
>>         currently that while none has three segments the last segment
>>         must be empty.   I think that is sufficient to keep people
>>         from becoming confused.
>>
>>     No, there's a very good reason.  Something that is not signed
>>     should not be accepted as a JSON Web Signature object.
>>      Acceptance of a JWS implies that the payload and protected
>>     headers were integrity protected from the signer; that is not
>>     true for "alg":"none".
>>
>>     Also, it's not clear that this change will break existing
>>     parsers.  For example, the NimbusDS parser would successfully
>>     parse a two-segment object as a "plain JWT"
>         java.text.ParseException: Invalid serialized plain/JWS/JWE
>         object: Missing second delimiter
>     From that very code you should be able to see that it plucks off
>     the header and looks for the algorithm value, creating a
>     "PlainJWT" object if alg=none.
>
>
> Ah, the risks of reading code.  I stand corrected.  At least the 
> top-level parsing works, so you could just adapt the PlainJWT.parse() 
> method.

So that would be the very definition of a breaking change.

>>     I would also be completely fine with an unsigned "header +
>>     content" structure (though I don't think it adds any value).  But
>>     it must be recognizably different from JWS.
>>
>     I am too, but from the opposite end -- why is it so important for
>     you to delete that single "." character?
>
>
> validation.  If something unsigned is ever accepted as a valid JWS, 
> then there's a huge downgrade risk.
>

I think that's a red herring. It's the same downgrade risk if someone 
sends alg:rot13 and your app doesn't want to accept that "signature" 
either. A JWS with alg:none should pass *only* if the signature field is 
empty, full stop.

  -- Justin

>>         > I don't normally jump into the discussion on this list, but
>>         I've been using the output of JOSE for quite some time now
>>         and am a committer on the NimbusDS JOSE JWT library. However,
>>         with tonight's call coming up (which I won't be able to make)
>>         I wanted to jump in and say that from my perspective,
>>         alg:none makes a lot of sense. There's a need for being able
>>         to send unsigned content with JOSE objects, and that's been
>>         pretty well established by others on the list here. As an
>>         implementor, though, I think it makes the most sense to have
>>         the unsigned content be parallel in structure to the signed
>>         content. When reading a string and constructing objects, our
>>         library parses the header and dispatches the parser based on
>>         the "alg" parameter.
>>         >
>>         >> Comment (by [email-masked] <mailto:[email-masked]>):
>>         >>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Aug 2013 10:09:58 -0400

On 8/20/13 9:49 AM, Justin Richer wrote:
>> [snip]
> either. A JWS with alg:none should pass *only* if the signature field 
> is empty, full stop.
>
>  -- Justin

+1

And to take it even a bit further. There will come a time in the future 
when HS256 is deemed to be insecure and SHOULD NOT be used because it's 
been hacked/compromised. At that point in time, all the implementations 
will have to have a way to not allow alg:256. Hence there could be no 
security difference between alg:hs256 and alg:none at some point in the 
future.

I realize I missed the call last night so maybe this is all mute:)

Thanks,
George

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Aug 2013 10:33:24 -0400

If I may summarize the call:

-- There was agreement that we should define a "header + data" format, with
no cryptographic protection

-- There was disagreement on whether that unprotected format should be part
of JWS, or something separate.  Two options were proposed:
1. Use JWS, but require that implementations MUST NOT accept "none" unless
explicitly directed to by an application
2. Define a new format, distinct from JWS, that just has header and payload
(no signature).  In the compact format, this would just have two
dot-separated components.

-- It was observed that either one of these options causes work for
existing implementations.  Option 1 causes them to expose API surface that
may not be there now (to specify acceptable algorithms).  Option 2 requires
a change to parsing.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Aug 2013 10:35:53 -0400

On Tue, Aug 20, 2013 at 9:49 AM, Justin Richer <[email-masked]> wrote:

>> implies that the payload and protected headers were integrity protected
>> from the signer; that is not true for "alg":"none".
>>

I realize we're trying to avoid those, but security risks are worth
breaking change.  And as Vladimir observed, it's not a huge change; in
fact, it's something that some implementations are basically doing already.

> either. A JWS with alg:none should pass *only* if the signature field is

If I'm an attacker, it it any harder for me to strip the signature field
than it is to change the "alg" field?

Plus, as several people observed on the call yesterday, there's a huge
difference between downgrading from "secure" to "less-secure" and
downgrading from "secure" to "completely unprotected".

--Richard

>>> recipe for

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Aug 2013 10:56:40 -0400

Thank you for the summary!

My only counter to 'Option 1' is that while the need to "specify 
acceptable algorithms" might not be present right now it will be present 
in the future for these existing protocols (e.g. MD5 is no longer 
considered secure). In that sense, I'd rather just have the appropriate 
infrastructure to deal with it now, rather than having to write code to 
handle the non-signed JWPs now, and then additionally having to write 
code to handle the insecure/no-long-supported signing algorithms in the 
future.

 From an implementation perspective, it doesn't seem that hard to 
specify the set of signing algorithms an application is willing to 
support. If the issue is that this will be layered into protocol 
libraries on top of pure JWS processing, then those libraries already 
need to have a mechanism to determine which algorithms they are willing 
to support. I can't imagine that an LOA4 use case is going to allow HS256.

Thanks again for the summary,
George

On 8/20/13 10:33 AM, Richard Barnes wrote:
> -- There was agreement that we should define a "header + data" format, 
> with no cryptographic protection
>
> -- There was disagreement on whether that unprotected format should be 
> part of JWS, or something separate.  Two options were proposed:
> 1. Use JWS, but require that implementations MUST NOT accept "none" 
> unless explicitly directed to by an application
> 2. Define a new format, distinct from JWS, that just has header and 
> payload (no signature).  In the compact format, this would just have 
> two dot-separated components.
>
> existing implementations.  Option 1 causes them to expose API surface 
> that may not be there now (to specify acceptable algorithms).  Option 
> 2 requires a change to parsing.
>
>
>
>
> On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher <[email-masked] 
>>>     It's important that something that is not signed is does not
>>>     pass JWS validation.  If something unsigned is ever accepted as
>>>     a valid JWS, then there's a huge downgrade risk.
>>>
>>
>>     I think that's a red herring. It's the same downgrade risk if
>>     someone sends alg:rot13 and your app doesn't want to accept that
>>     "signature" either. A JWS with alg:none should pass *only* if the
>>     signature field is empty, full stop.
>>
>>      -- Justin
>
>     +1
>
>     And to take it even a bit further. There will come a time in the
>     future when HS256 is deemed to be insecure and SHOULD NOT be used
>     because it's been hacked/compromised. At that point in time, all
>     the implementations will have to have a way to not allow alg:256.
>     Hence there could be no security difference between alg:hs256 and
>     alg:none at some point in the future.
>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Mike Jones <[email-masked]>
Date: Tue, 20 Aug 2013 17:33:14 +0000

Please permit me add a couple more points to the summary:

  - Ekr suggested the possibility of having libraries, by default, not accept "none" unless called in a way in which the application indicates that it is acceptable.  Mike agreed to take an action item to add this text to the document as a step towards resolving the issue in a way that addresses the concerns expressed about the possibility of downgrade attacks.

  - Tony and John pointed out that the issue being discussed is more general than just "none" - it's really the issue of what algorithms are acceptable to the application.  They said that applications could pass in a list of acceptable algorithms, which is more general than special-casing "none".

  - Mike pointed out that people are likely to use general JOSE libraries processing all formats (JWS, JWE, unsigned) and so whether the wire format of an unsigned object looks like JWS (as it does now) or something else, libraries would still need to facilitate applications being written safely, as all kinds of objects can be processed by these libraries, independent of the wire format choice.  Thus, the defense against downgrade attacks needs to happen in the library interface design, as ekr suggested.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, August 20, 2013 7:33 AM
To: George Fletcher
Cc: Justin Richer; John Bradley; Mike Jones; jose issue tracker; [email-masked]; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

-- There was agreement that we should define a "header + data" format, with no cryptographic protection

-- There was disagreement on whether that unprotected format should be part of JWS, or something separate.  Two options were proposed:
1. Use JWS, but require that implementations MUST NOT accept "none" unless explicitly directed to by an application
2. Define a new format, distinct from JWS, that just has header and payload (no signature).  In the compact format, this would just have two dot-separated components.

-- It was observed that either one of these options causes work for existing implementations.  Option 1 causes them to expose API surface that may not be there now (to specify acceptable algorithms).  Option 2 requires a change to parsing.

On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

It's important that something that is not signed is does not pass JWS validation.  If something unsigned is ever accepted as a valid JWS, then there's a huge downgrade risk.

I think that's a red herring. It's the same downgrade risk if someone sends alg:rot13 and your app doesn't want to accept that "signature" either. A JWS with alg:none should pass *only* if the signature field is empty, full stop.

 -- Justin

+1

And to take it even a bit further. There will come a time in the future when HS256 is deemed to be insecure and SHOULD NOT be used because it's been hacked/compromised. At that point in time, all the implementations will have to have a way to not allow alg:256. Hence there could be no security difference between alg:hs256 and alg:none at some point in the future.

Thanks,
George

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 20 Aug 2013 14:41:50 -0400

This is perhaps a tiny nit, but I heard you take an action to write 
proposed text for discussion by the working group. I think this is an 
issue that needs to be resolved by a concrete set of agreed upon steps 
and actual text before interim action is taken to modify the documents.

Karen

On 8/20/13 1:33 PM, Mike Jones wrote:
> - Ekr suggested the possibility of having libraries, by default, not 
> accept "none" unless called in a way in which the application 
> indicates that it is acceptable.  Mike agreed to take an action item 
> to add this text to the document as a step towards resolving the issue 
> in a way that addresses the concerns expressed about the possibility 
> of downgrade attacks.
>
> - Tony and John pointed out that the issue being discussed is more 
> general than just "none" -- it's really the issue of what algorithms 
> are acceptable to the application.  They said that applications could 
> pass in a list of acceptable algorithms, which is more general than 
> special-casing "none".
>
> - Mike pointed out that people are likely to use general JOSE 
> libraries processing all formats (JWS, JWE, unsigned) and so whether 
> the wire format of an unsigned object looks like JWS (as it does now) 
> or something else, libraries would still need to facilitate 
> applications being written safely, as all kinds of objects can be 
> processed by these libraries, independent of the wire format choice.  
> Thus, the defense against downgrade attacks needs to happen in the 
> library interface design, as ekr suggested.
>
> -- Mike
>
> *From:*Richard Barnes [mailto:[email-masked]]
> *Sent:* Tuesday, August 20, 2013 7:33 AM
> *To:* George Fletcher
> *Cc:* Justin Richer; John Bradley; Mike Jones; jose issue tracker; 
> *Subject:* Re: [jose] #36: Algorithm "none" should be removed
>
>         pass JWS validation.  If something unsigned is ever accepted
>         as a valid JWS, then there's a huge downgrade risk.
>
>
> because it's been hacked/compromised. At that point in time, all the 
> implementations will have to have a way to not allow alg:256. Hence 
> there could be no security difference between alg:hs256 and alg:none 
> at some point in the future.
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Aug 2013 14:43:48 -0400

I have already posted proposed text for Option 2 (defining a new,
two-component, one-dot, no-crypto syntax)
<http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch

Would be interested in whether anyone finds that text objectionable.

On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue <[email-masked]>wrote:

> proposed text for discussion by the working group. I think this is an issue
> that needs to be resolved by a concrete set of agreed upon steps and actual
> text before interim action is taken to modify the documents.
>
> Karen
>
>
>  Please permit me add a couple more points to the summary:****
>
> ** **
>
> accept “none” unless called in a way in which the application indicates
> that it is acceptable.  Mike agreed to take an action item to add this text
> to the document as a step towards resolving the issue in a way that
> addresses the concerns expressed about the possibility of downgrade attacks.
> ****
>
> ** **
>
> general than just “none” – it’s really the issue of what algorithms are
> acceptable to the application.  They said that applications could pass in a
> list of acceptable algorithms, which is more general than special-casing
> “none”.****
>
> ** **
>
>   - Mike pointed out that people are likely to use general JOSE libraries
> processing all formats (JWS, JWE, unsigned) and so whether the wire format
> of an unsigned object looks like JWS (as it does now) or something else,
> libraries would still need to facilitate applications being written safely,
> as all kinds of objects can be processed by these libraries, independent of
> the wire format choice.  Thus, the defense against downgrade attacks needs
> to happen in the library interface design, as ekr suggested.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> If I may summarize the call: ****
>
> ** **
>
> with no cryptographic protection****
>
> ** **
>
> part of JWS, or something separate.  Two options were proposed:****
>
> explicitly directed to by an application****
>
> payload (no signature).  In the compact format, this would just have two
> dot-separated components.****
>
> ** **
>
> a change to parsing.****
> On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher <[email-masked]>
> wrote:****
>
> ** **
>
> On 8/20/13 9:49 AM, Justin Richer wrote:****
>
>  ** **
>
> On 08/19/2013 05:46 PM, Richard Barnes wrote:****
>
>  ** **
>
> [snip] ****
>
> ** **
>
> there's a huge downgrade risk.****
>
> ** **
>
>
>  -- Justin****
> George****
> jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose
>
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 20 Aug 2013 18:50:30 +0000

I don't find the text objectionable but I find the concept/proposal objectionable, as I don't see the need for this since there is already a working solution and with the option that EKR proposed make this a manageable option as this is how we limit cipher suites today with application that need to be  FIPS compliant.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, August 20, 2013 11:44 AM
To: Karen ODonoghue
Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]; John Bradley; Justin Richer; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

I have already posted proposed text for Option 2 (defining a new, two-component, one-dot, no-crypto syntax)
<http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch>

On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:
This is perhaps a tiny nit, but I heard you take an action to write proposed text for discussion by the working group. I think this is an issue that needs to be resolved by a concrete set of agreed upon steps and actual text before interim action is taken to modify the documents.

Karen

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, August 20, 2013 7:33 AM
To: George Fletcher
Cc: Justin Richer; John Bradley; Mike Jones; jose issue tracker; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

[snip]

 -- Justin

+1

Thanks,
George

jose mailing list

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Aug 2013 15:43:36 -0400

It's probably worth noting that this idea that whenever you verify an
object, you have to specify a set of acceptable algorithms, is a completely
new one in the space of crypto APIs.  Every API out there that takes a
signed object (cert or SignedData) just tells you whether the signature on
the object validates, leaving it to the application to check the algorithm.

CAPI/X.509: <
http://msdn.microsoft.com/en-us/library/windows/desktop/aa377166(v=vs.85).aspx
BouncyCastle/X.509: <
http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/CertificateVerifyer.html
OpenSSL/CMS: <http://www.openssl.org/docs/crypto/CMS_verify.html>
OpenSSL/X.509: <http://www.openssl.org/docs/crypto/X509_verify_cert.html>
NSS/CMS: <
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#98
NSS/X.509: <
https://developer.mozilla.org/en-US/docs/NSS_Certificate_Functions#CERT_VerifyCert

In *none* of these APIs is it the job of the verification library to do
algorithm checking.

This is yet another way that layering violations in the OpenID use case are
being used to force the crypto layer to deal with things the application
layer should be doing.

It's just bad, insecure design.  It's not worth it to avoid a minor parser
change.

--Richard

On Tue, Aug 20, 2013 at 2:50 PM, Anthony Nadalin <[email-masked]>wrote:

>  I don’t find the text objectionable but I find the concept/proposal
> objectionable, as I don’t see the need for this since there is already a
> working solution and with the option that EKR proposed make this a
> manageable option as this is how we limit cipher suites today with
> application that need to be  FIPS compliant.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Tuesday, August 20, 2013 11:44 AM
> *To:* Karen ODonoghue
> *Cc:* George Fletcher; Mike Jones; jose issue tracker; [email-masked];
> John Bradley; Justin Richer;
> two-component, one-dot, no-crypto syntax)****
>
> <
> http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch
> >****
>
> ** **
>
> Would be interested in whether anyone finds that text objectionable.****
>
> ** **
>
> On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue <[email-masked]>
> wrote:****
>
> Karen****
> On 8/20/13 1:33 PM, Mike Jones wrote:****
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 20 Aug 2013 20:37:14 +0000

+1

Exactly what I was going to say!

________________________________
From: Anthony Nadalin
Sent: 8/20/2013 11:49 AM
To: Richard Barnes; Karen ODonoghue
Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]; John Bradley; Justin Richer; [email-masked]
Subject: RE: [jose] #36: Algorithm "none" should be removed

I don’t find the text objectionable but I find the concept/proposal objectionable, as I don’t see the need for this since there is already a working solution and with the option that EKR proposed make this a manageable option as this is how we limit cipher suites today with application that need to be  FIPS compliant.

Karen

  - Ekr suggested the possibility of having libraries, by default, not accept “none” unless called in a way in which the application indicates that it is acceptable.  Mike agreed to take an action item to add this text to the document as a step towards resolving the issue in a way that addresses the concerns expressed about the possibility of downgrade attacks.

  - Tony and John pointed out that the issue being discussed is more general than just “none” – it’s really the issue of what algorithms are acceptable to the application.  They said that applications could pass in a list of acceptable algorithms, which is more general than special-casing “none”.

                                                                -- Mike

[snip]

 -- Justin

+1

Thanks,
George

jose mailing list

---

From: Vladimir Dzhuvinov / NimbusDS <[email-masked]>
Date: Wed, 21 Aug 2013 12:51:25 +0300

Hi Richard,

On Tue, 2013-08-20 at 15:43 -0400, Richard Barnes wrote:
> object, you have to specify a set of acceptable algorithms, is a
> completely new one in the space of crypto APIs.  Every API out there
> that takes a signed object (cert or SignedData) 

Indeed, and I don't think the x.509 cert will parse at all with a
missing signature :)

> just tells you whether the signature on the object validates, leaving
> it to the application to check the algorithm.

The BouncyCastle interface that you linked to is deprecated, so I'll
discuss the standard java.security.certificate.Certificate class
instead.

To arrive at a Certificate instance you first typically parse the raw
cert bytes with a java.security.cert.CertificateFactory. It will throw a
java.security.cert.CertificateException if the signature is missing.

We then call the Certificate.verify() method to check the signature, and
here we have the choice to use the JVM's default crypto library or an
external one like BouncyCastle's. I haven't looked at the source code,
but I don't think it's plausible to assume the underlying library would
allow an algorithm that is not meant for signing. The verify method
specifies a concrete exception - java.security.NoSuchAlgorithmException
for that situation.

Why doesn't the crypto library do any further checking of the signature
algorithm? Because the X.509 spec says any signature algorithm may be
used, and the java.security.cert.X509Certificate class complies
correctly with that requirement.

http://tools.ietf.org/html/rfc5280#section-4.1.1.2

If the application developers choose to allow only specific signature
algorithms, the X.509 spec allows them to do so, and they can call the
X509Certificate.getSigAlgName() method for that, before or after the
signature validation. 

Vladimir

> 
> CAPI/X.509:
> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa377166(v=vs.85).aspx>
> BouncyCastle/X.509:
> <http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/CertificateVerifyer.html>
> OpenSSL/X.509:
> <http://www.openssl.org/docs/crypto/X509_verify_cert.html>
> NSS/CMS:
> <http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#98>
> 
> NSS/X.509:
> <https://developer.mozilla.org/en-US/docs/NSS_Certificate_Functions#CERT_VerifyCert>
> 
> 
> In *none* of these APIs is it the job of the verification library to
> do algorithm checking.  
> 
> 
> This is yet another way that layering violations in the OpenID use
> case are being used to force the crypto layer to deal with things the
> application layer should be doing.  
> 
> 
> It's just bad, insecure design.  It's not worth it to avoid a minor
> parser change.
> 
> 
> --Richard
> 
> 
> On Tue, Aug 20, 2013 at 2:50 PM, Anthony Nadalin
> <[email-masked]> wrote:
>         I don’t find the text objectionable but I find the
>         concept/proposal objectionable, as I don’t see the need for
>         this since there is already a working solution and with the
>         option that EKR proposed make this a manageable option as this
>         is how we limit cipher suites today with application that need
>         to be  FIPS compliant.
>         
>          
>         
>         Cc: George Fletcher; Mike Jones; jose issue tracker;
>         [email-masked]; John Bradley; Justin Richer;
>         I have already posted proposed text for Option 2 (defining a
>         new, two-component, one-dot, no-crypto syntax)
>         
>         On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue
>         <[email-masked]> wrote:
>         
>                 This is perhaps a tiny nit, but I heard you take an
>                 action to write proposed text for discussion by the
>                 working group. I think this is an issue that needs to
>                 be resolved by a concrete set of agreed upon steps and
>                 actual text before interim action is taken to modify
>                 the documents.
>                 
>                 Karen
>                 
>                 
>                 
>                           - Ekr suggested the possibility of having
>                         libraries, by default, not accept “none”
>                         unless called in a way in which the
>                         application indicates that it is acceptable.
>                         Mike agreed to take an action item to add this
>                         text to the document as a step towards
>                         resolving the issue in a way that addresses
>                         the concerns expressed about the possibility
>                         of downgrade attacks.
>                         
>                          
>                         
>                           - Tony and John pointed out that the issue
>                         being discussed is more general than just
>                         “none” – it’s really the issue of what
>                         algorithms are acceptable to the application.
>                         They said that applications could pass in a
>                         list of acceptable algorithms, which is more
>                         general than special-casing “none”.
>                         
>                          
>                         
>                           - Mike pointed out that people are likely to
>                         use general JOSE libraries processing all
>                         formats (JWS, JWE, unsigned) and so whether
>                         the wire format of an unsigned object looks
>                         like JWS (as it does now) or something else,
>                         libraries would still need to facilitate
>                         applications being written safely, as all
>                         kinds of objects can be processed by these
>                         libraries, independent of the wire format
>                         choice.  Thus, the defense against downgrade
>                         attacks needs to happen in the library
>                         interface design, as ekr suggested.
>                         
>                          
>                         
>                         
>                         -- Mike
>                         
>                          
>                         
>                         Cc: Justin Richer; John Bradley; Mike Jones;
>                         jose issue tracker; [email-masked];
>                         -- There was agreement that we should define a
>                         "header + data" format, with no cryptographic
>                         protection
>                         
>                         
>                          
>                         
>                         
>                         -- There was disagreement on whether that
>                         unprotected format should be part of JWS, or
>                         something separate.  Two options were
>                         proposed:
>                         
>                         
>                         1. Use JWS, but require that implementations
>                         MUST NOT accept "none" unless explicitly
>                         directed to by an application
>                         
>                         
>                         2. Define a new format, distinct from JWS,
>                         that just has header and payload (no
>                         signature).  In the compact format, this would
>                         just have two dot-separated components.
>                         
>                         
>                          
>                         
>                         
>                         -- It was observed that either one of these
>                         options causes work for existing
>                         implementations.  Option 1 causes them to
>                         expose API surface that may not be there now
>                         (to specify acceptable algorithms).  Option 2
>                         requires a change to parsing.
>                         
>                         
>                          
>                         
>                         
>                          
>                         
>                         
>                          
>                         
>                                         pass JWS validation.  If
>                                         something unsigned is ever
>                                         accepted as a valid JWS, then
>                                 I think that's a red herring. It's the
>                                 same downgrade risk if someone sends
>                                 alg:rot13 and your app doesn't want to
>                                 accept that "signature" either. A JWS
>                                 with alg:none should pass *only* if
>                                 the signature field is empty, full
>                                 stop. 
>                                 
>                                  -- Justin
>                                 
>                                 
>                         
>                         
>                         +1
>                         
>                         And to take it even a bit further. There will
>                         come a time in the future when HS256 is deemed
>                         to be insecure and SHOULD NOT be used because
>                         it's been hacked/compromised. At that point in
>                         time, all the implementations will have to
>                         have a way to not allow alg:256. Hence there
>                         could be no security difference between
>                         alg:hs256 and alg:none at some point in the
>                         future.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Aug 2013 07:19:29 -0700

Given that JWT can mandate that the none algorithm be required, I believe
that it should be possible to lower the requirements level on the none
algorithm from MUST to SHOULD or similar.

The required algorithms for JWT do not have to be the required algorithms
for the JOSE documents.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Tuesday, August 20, 2013 1:37 PM
To: Anthony Nadalin; Richard Barnes; Karen ODonoghue
Cc: George Fletcher; jose issue tracker; [email-masked]; John Bradley; Justin
Richer; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

+1

  _____  

From: Anthony Nadalin
Sent: 8/20/2013 11:49 AM
To: Richard Barnes; Karen ODonoghue
Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]; John
Bradley; Justin Richer; [email-masked]
Subject: RE: [jose] #36: Algorithm "none" should be removed

I don't find the text objectionable but I find the concept/proposal
objectionable, as I don't see the need for this since there is already a
working solution and with the option that EKR proposed make this a
manageable option as this is how we limit cipher suites today with
application that need to be  FIPS compliant.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Tuesday, August 20, 2013 11:44 AM
To: Karen ODonoghue
Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]; John
Bradley; Justin Richer; [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

This is perhaps a tiny nit, but I heard you take an action to write proposed
text for discussion by the working group. I think this is an issue that
needs to be resolved by a concrete set of agreed upon steps and actual text
before interim action is taken to modify the documents.

Karen

  - Ekr suggested the possibility of having libraries, by default, not
accept "none" unless called in a way in which the application indicates that
it is acceptable.  Mike agreed to take an action item to add this text to
the document as a step towards resolving the issue in a way that addresses
the concerns expressed about the possibility of downgrade attacks.

  - Tony and John pointed out that the issue being discussed is more general
than just "none" - it's really the issue of what algorithms are acceptable
to the application.  They said that applications could pass in a list of
acceptable algorithms, which is more general than special-casing "none".

to happen in the library interface design, as ekr suggested.

                                                                -- Mike

Cc: Justin Richer; John Bradley; Mike Jones; jose issue tracker;

-- It was observed that either one of these options causes work for existing
implementations.  Option 1 causes them to expose API surface that may not be
there now (to specify acceptable algorithms).  Option 2 requires a change to
parsing.

[snip] 

I think that's a red herring. It's the same downgrade risk if someone sends
alg:rot13 and your app doesn't want to accept that "signature" either. A JWS
with alg:none should pass *only* if the signature field is empty, full stop.

 -- Justin

+1

And to take it even a bit further. There will come a time in the future when
HS256 is deemed to be insecure and SHOULD NOT be used because it's been
hacked/compromised. At that point in time, all the implementations will have
to have a way to not allow alg:256. Hence there could be no security
difference between alg:hs256 and alg:none at some point in the future.

Thanks,
George

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Aug 2013 15:11:20 +0000

If we lower the requirement on "none" to optional in JWS and make it required in JWT, possibly still including the language that ekr suggested, can we close this issue and move on?

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, August 21, 2013 7:19 AM
To: Mike Jones
Cc: [email-masked]; 'John Bradley'
Subject: RE: [jose] #36: Algorithm "none" should be removed

Given that JWT can mandate that the none algorithm be required, I believe that it should be possible to lower the requirements level on the none algorithm from MUST to SHOULD or similar.

The required algorithms for JWT do not have to be the required algorithms for the JOSE documents.

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, August 20, 2013 1:37 PM
To: Anthony Nadalin; Richard Barnes; Karen ODonoghue
Cc: George Fletcher; jose issue tracker; [email-masked]<mailto:[email-masked]>; John Bradley; Justin Richer; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

+1

Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]<mailto:[email-masked]>; John Bradley; Justin Richer; [email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, August 20, 2013 11:44 AM
To: Karen ODonoghue
Cc: George Fletcher; Mike Jones; jose issue tracker; [email-masked]<mailto:[email-masked]>; John Bradley; Justin Richer; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

Karen

                                                                -- Mike

[snip]

 -- Justin

+1

Thanks,
George

jose mailing list

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Aug 2013 11:53:05 -0400

If we are going to keep "none" as a JWS algorithm, then I would view it as
necessary for it to be OPTIONAL.  So yes, that would help.

However, I think it's still unacceptable for verify(jws) to return true
when there is no signature.  I'm fine with having an unsigned content type
(see my proposed text), but it should cause verify() to throw
NotAJWSException.

--Richard

On Wed, Aug 21, 2013 at 11:11 AM, Mike Jones <[email-masked]>wrote:

>  If we lower the requirement on “none” to optional in JWS and make it
> required in JWT, possibly still including the language that ekr suggested,
> can we close this issue and move on?****
>
> ** **
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Wednesday, August 21, 2013 7:19 AM
> *To:* Mike Jones
> *Cc:* [email-masked]; 'John Bradley'
>
> *Subject:* RE: [jose] #36: Algorithm "none" should be removed****
>
>  ** **
>
> algorithm from MUST to SHOULD or similar.****
>
> ** **
>
> for the JOSE documents.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Mike Jones
> *Sent:* Tuesday, August 20, 2013 1:37 PM
> *To:* Anthony Nadalin; Richard Barnes; Karen ODonoghue
> *Cc:* George Fletcher; jose issue tracker; [email-masked]; John Bradley;
> Justin Richer; [email-masked]
> Exactly what I was going to say!****
>   ------------------------------
>
> *From: *Anthony Nadalin
> *Sent: *8/20/2013 11:49 AM
> *To: *Richard Barnes; Karen ODonoghue
> *Cc: *George Fletcher; Mike Jones; jose issue tracker; [email-masked];
> *Subject: *RE: [jose] #36: Algorithm "none" should be removed****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Richard Barnes

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 22 Aug 2013 11:01:58 +1000

Mike said:
“the defense against downgrade attacks needs to happen in the library interface design, as ekr suggested”

I think there is general agreement (if “none” is allowed at all) that the JOSE library interface is the place to make sure an app can’t accidentally accept an "alg": "none" message when it only expected authentic messages.

However, we are not writing a library interface; we are specifying a message format.

I doubt any advice in a JOSE spec about library interfaces will be given much attention. Libraries are just as likely to develop an interface that matches the structure of the JOSE specs – and that structure currently treats "none" as a signature algorithm.

The Nimbus JOSE+JWT library [https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home] appears to handle "alg": "none" fairly well. It treats "alg": "none" as a distinct type of JOSE message (PlainObject), distinct from a JWE (JWEObject), and distinct from a JWS (JWSObject). Calling JWSObject.parse(<"alg": "none" message>) fails. This is good.
The spec should reflect this desirable structure. It should not pretend “none” is a variety of signed message.

This would be easy if we had a JOSE spec, with sections (or other specs) for signed, MACed, directly encrypted, plain, key exchange+encryption, etc – instead of 2 buckets (JWS, JWE) that everything has to fit in.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Aug 2013 00:32:06 -0400

I would be happy enough with 3 buckets:
1. Things that are integrity-protected (JWS)
2. Things that are encrypted and integrity-protected (JWE)
3. Things that are not protected (TBD; JWP in my proposed text)

On Wed, Aug 21, 2013 at 9:01 PM, Manger, James H <
[email-masked]> wrote:

> Mike said:****
>
> “the defense against downgrade attacks needs to happen in the library
> interface design, as ekr suggested”****
>
> ** **
>
> I think there is general agreement (if “none” is allowed at all) that the
> JOSE library interface is the place to make sure an app can’t accidentally
> accept an "alg": "none" message when it only expected authentic messages.*
> ***
>
> ** **
>
> However, we are not writing a library interface; we are specifying a
> message format.****
>
> ** **
>
> I doubt any advice in a JOSE spec about library interfaces will be given
> much attention. Libraries are just as likely to develop an interface that
> matches the structure of the JOSE specs – and that structure currently
> treats "none" as a signature algorithm.****
>
> ** **
>
> The Nimbus JOSE+JWT library [
> https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home] appears to
> handle "alg": "none" fairly well. It treats "alg": "none" as a distinct
> type of JOSE message (PlainObject), distinct from a JWE (JWEObject), and
> distinct from a JWS (JWSObject). Calling JWSObject.parse(<"alg": "none"
> message>) fails. This is good.****
>
> The spec should reflect this desirable structure. It should not pretend
> “none” is a variety of signed message.****
>
> ** **
>
> This would be easy if we had a JOSE spec, with sections (or other specs)
> for signed, MACed, directly encrypted, plain, key exchange+encryption, etc
> – instead of 2 buckets (JWS, JWE) that everything has to fit in.****
>
> ** **
>
> --****
>
> James Manger****
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 22 Aug 2013 08:02:04 -0700

Mike, et al.

Do you see any reason why there should ever be a mix of signed and unsigned
in the same message?  I understand this cannot happen for JWT, however it
will be able to occur for the JSON version of the JOSE data structures.

This would be a case where many of the current systems which have different
objects returned from a library would be in deep trouble as they would need
to return a  JOSE_Signed for part of the object and a JOSE_Unsigned for
another part. 

I think it would be a good idea if these concepts could not be mixed
together.  How are other system implementers dealing with this possibility?
Do you only handle the compact serialization and thus have not thought about
it?

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Wednesday, August 21, 2013 9:32 PM
To: Manger, James H
Cc: Mike Jones; jose issue tracker; [email-masked];
[email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

On Wed, Aug 21, 2013 at 9:01 PM, Manger, James H
<[email-masked]> wrote:

Mike said:

"the defense against downgrade attacks needs to happen in the library
interface design, as ekr suggested"

I think there is general agreement (if "none" is allowed at all) that the
JOSE library interface is the place to make sure an app can't accidentally
accept an "alg": "none" message when it only expected authentic messages.

However, we are not writing a library interface; we are specifying a message
format.

I doubt any advice in a JOSE spec about library interfaces will be given
much attention. Libraries are just as likely to develop an interface that
matches the structure of the JOSE specs - and that structure currently
treats "none" as a signature algorithm.

The Nimbus JOSE+JWT library
[https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home] appears to handle
"alg": "none" fairly well. It treats "alg": "none" as a distinct type of
JOSE message (PlainObject), distinct from a JWE (JWEObject), and distinct
from a JWS (JWSObject). Calling JWSObject.parse(<"alg": "none" message>)
fails. This is good.

The spec should reflect this desirable structure. It should not pretend
"none" is a variety of signed message.

This would be easy if we had a JOSE spec, with sections (or other specs) for
signed, MACed, directly encrypted, plain, key exchange+encryption, etc -
instead of 2 buckets (JWS, JWE) that everything has to fit in.

--

James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Aug 2013 15:18:36 +0000

I don't know of any use cases requiring that.  You're right that it can't happen in the Compact Serialization.  It can only happen in the JSON Serialization because of the option of having unprotected header parameters (I concept I'm still dubious of).

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, August 22, 2013 8:02 AM
To: Mike Jones
Cc: [email-masked]
Subject: RE: [jose] #36: Algorithm "none" should be removed

Mike, et al.

Do you see any reason why there should ever be a mix of signed and unsigned in the same message?  I understand this cannot happen for JWT, however it will be able to occur for the JSON version of the JOSE data structures.

This would be a case where many of the current systems which have different objects returned from a library would be in deep trouble as they would need to return a  JOSE_Signed for part of the object and a JOSE_Unsigned for another part.

I think it would be a good idea if these concepts could not be mixed together.  How are other system implementers dealing with this possibility?  Do you only handle the compact serialization and thus have not thought about it?

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, August 21, 2013 9:32 PM
To: Manger, James H
Cc: Mike Jones; jose issue tracker; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #36: Algorithm "none" should be removed

On Wed, Aug 21, 2013 at 9:01 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
Mike said:
"the defense against downgrade attacks needs to happen in the library interface design, as ekr suggested"

I think there is general agreement (if "none" is allowed at all) that the JOSE library interface is the place to make sure an app can't accidentally accept an "alg": "none" message when it only expected authentic messages.

I doubt any advice in a JOSE spec about library interfaces will be given much attention. Libraries are just as likely to develop an interface that matches the structure of the JOSE specs - and that structure currently treats "none" as a signature algorithm.

The Nimbus JOSE+JWT library [https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home] appears to handle "alg": "none" fairly well. It treats "alg": "none" as a distinct type of JOSE message (PlainObject), distinct from a JWE (JWEObject), and distinct from a JWS (JWSObject). Calling JWSObject.parse(<"alg": "none" message>) fails. This is good.
The spec should reflect this desirable structure. It should not pretend "none" is a variety of signed message.

This would be easy if we had a JOSE spec, with sections (or other specs) for signed, MACed, directly encrypted, plain, key exchange+encryption, etc - instead of 2 buckets (JWS, JWE) that everything has to fit in.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 22 Aug 2013 09:27:13 -0700

I don't understand your second sentence below.  It can happen because of
having multiple signers.  For example, the first could be RS256 and the
second could be none.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 8:19 AM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] #36: Algorithm "none" should be removed

I don't know of any use cases requiring that.  You're right that it can't
happen in the Compact Serialization.  It can only happen in the JSON
Serialization because of the option of having unprotected header parameters
(I concept I'm still dubious of).

                                                            -- Mike

Mike, et al.

Jim

Mike said:

--

James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Aug 2013 16:37:25 +0000

It can happen in the single recipient case for the JSON Serialization by placing content in a header parameter within the "header" member, which is not integrity protected (about which I'd meant to write "a concept I'm still dubious of").

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, August 22, 2013 9:27 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] #36: Algorithm "none" should be removed

I don't understand your second sentence below.  It can happen because of having multiple signers.  For example, the first could be RS256 and the second could be none.

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, August 22, 2013 8:19 AM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] #36: Algorithm "none" should be removed

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, August 22, 2013 8:02 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] #36: Algorithm "none" should be removed

Mike, et al.

Jim

--
James Manger