Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

From: "Vladimir Dzhuvinov" <[email-masked]>
Date: Tue, 29 Apr 2014 07:56:00 -0700

Hello Kathleen,

I found about 80 messages from August 2013 regarding the alg "none"
discussion, you can view them at

http://www.ietf.org/mail-archive/web/jose/current/thrd3.html

(scroll down to subject "#36...")

The utility of having JOSE-structured objects with protection provided
at a higher level (e.g. TLS, as used in OpenID Connect) was generally
understood and agreed. How to write this up and structure it in the
overall context of the JOSE (and JWT) specs -- there was a lot of
discussion about that.

Here I would like to add something that may not be immediately apparent,
but is important from a security perspective -- while "none" alg JOSE
objects are described in the JWS spec, they have a very distinct
structure from JWS and JWE objects -- they have only two parts -- the
JOSE header and the payload. This makes it relatively simple and
foolproof to distinguish a "none" alg message, without even having to
inspect the JOSE header.

Implementers can apply this distinction at code level too. The open
source Nimbus JOSE+JWT library for example uses three separate classes
to provide type safety -- PlainObject (alg none), JWSObject (signature)
and JWEObject (encrypted object). So "none" alg objects are technically
quite distinct from JWS objects, despite being described in the same
spec.

Regards,

Vladimir

> -------- Original Message --------
> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
> From: Kathleen Moriarty <[email-masked]>
> Date: Mon, April 28, 2014 3:11 pm
> To: Justin Richer <[email-masked]>
> Cc: Brian Campbell <[email-masked]>, Michael Jones
> <[email-masked]>,  "[email-masked]" <[email-masked]>, 
> "<[email-masked]>"
> <[email-masked]>,  Vladimir
> Dzhuvinov <[email-masked]>
> 
> 
> Thanks for the responses on this, it is helpful to see them from a
> range of folks.
> 
> 
> On Mon, Apr 28, 2014 at 10:07 AM, Justin Richer <[email-masked]> wrote:
> > +1
> >
> > Basically, JOSE defines both crypto processes and container mechanisms for
> > those processes. "alg:none" lets you use the container without the crypto in
> > a way that's compatible with using the same contianer with crypto. Code
> > reuse and parallelism are awesome. But by explicitly calling out that a
> > thing is unsigned, an app can decide whether or not it likes unsigned stuff
> > and act accordingly.
> >
> >  -- Justin
> >
> >
> >
> > On 04/25/2014 06:17 PM, Brian Campbell wrote:
> >
> > Plaintext JWSs haven't been free of controversy but the topic has been
> > discussed many times and the [rough] consensus of the WG is that the "none"
> > JWS alg is useful. It is in use by the finalized versions of OpenID Connect,
> > as Vladimir has alluded to. And it has been fairly wildly deployed in
> > production use.
> >
> > The "Plaintext JWS Security Considerations" in section 8.5 of JWA [1]
> > represents the consensus the WG came to, which keeps the "none" alg but
> > mandates that implementations "MUST NOT accept such objects as valid unless
> > the application specifies that it is acceptable for a specific object."
> >
> > [1]
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5
> >
> > Vladimir
> > On Fri, Apr 25, 2014 at 2:51 PM, Kathleen Moriarty
> > <[email-masked]> wrote:
> >>
> >> Thanks, Vladimir.
> >>
> >> Is there consensus in the WG that this is the right thing to do?  I'm
> >> expecting some push-back on this one and want to make sure it has
> >> consensus behind it.  I have heard of a couple of objections already.
> >>
> >> On Thu, Apr 17, 2014 at 2:10 PM, Vladimir Dzhuvinov
> >> <[email-masked]> wrote:
> >> >> Thanks, Vladimir.
> >> >>
> >> >> How would they be secured then?  With the current threat landscape, it
> >> >> seems odd that we would be putting forth a method that is not secured?
> >> >>  Does this rely on transport for security?
> >> >
> >> > Yes, securing the JWS message with TLS for instance, as Mike just
> >> > pointed
> >> > out in the his response.
> >> >
> >> > JWT-encoded ID tokens in OpenID Connect is one such example, but only
> >> > when
> >> > the token is returned from the OAuth 2.0 token endpoint where TLS is
> >> > mandatory, clients can then register to receive plaintext ID tokens:
> >> >
> >> > http://openid.net/specs/openid-connect-core-1_0.html#IDToken
> >> >
> >> >
> >> > There is a section in the JWA spec to instruct developers of the various
> >> > security
> >> > considerations regarding use of "none" alg JWS:
> >> >
> >> >
> >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5
> >> >
> >> >
> >> > Vladimir
> >> >
> >> >
> >> >
> >> >> On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <
> >> >> [email-masked]> wrote:
> >> >>
> >> >> > Hi Kathleen,
> >> >> >
> >> >> >
> >> >> > > Section 3.6 - Can you explain why would this be included?  If you
> >> >> > > are
> >> >> > not going to sign, I am not sure why one would use JOSE at all.
> >> >> > >
> >> >> >
> >> >> > Perhaps the most popular application of JWS today is to construct
> >> >> > JSON
> >> >> > Web Tokens (JWT), such as the ID tokens in OpenID Connect. The JWT
> >> >> > spec
> >> >> > permits plain tokens that don't have a signature and this is enabled
> >> >> > by
> >> >> > the special case "none" alg in JWS.
> >> >> >
> >> >> > Plaintext JWTs are explained here:
> >> >> >
> >> >> >
> >> >> > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-6
> >> >> >
> >> >> >
> >> >> > Vladimir
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Best regards,
> >> >> Kathleen
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >>
> >> _______________________________________________
> >> jose mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/jose
> >
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/jose
> >
> >
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 29 Apr 2014 11:02:34 -0700

Vladimir,

I would be quick to point out that this distinction is true only for the
compact encoding.  It is not true for the JSON encoding where you need to
figure out from alg field what you are expecting as people can give you
things which are not so clear cut.  (A JSON object with alg none and with a
signature field for example.)

Jim

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Tuesday, April 29, 2014 7:56 AM
To: Kathleen Moriarty
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Hello Kathleen,

The utility of having JOSE-structured objects with protection provided at a
higher level (e.g. TLS, as used in OpenID Connect) was generally understood
and agreed. How to write this up and structure it in the overall context of
the JOSE (and JWT) specs -- there was a lot of discussion about that.

Here I would like to add something that may not be immediately apparent, but
is important from a security perspective -- while "none" alg JOSE objects
are described in the JWS spec, they have a very distinct structure from JWS
and JWE objects -- they have only two parts -- the JOSE header and the
payload. This makes it relatively simple and foolproof to distinguish a
"none" alg message, without even having to inspect the JOSE header.

Implementers can apply this distinction at code level too. The open source
Nimbus JOSE+JWT library for example uses three separate classes to provide
type safety -- PlainObject (alg none), JWSObject (signature) and JWEObject
(encrypted object). So "none" alg objects are technically quite distinct
from JWS objects, despite being described in the same spec.

Regards,

Vladimir

> > Basically, JOSE defines both crypto processes and container 
> > mechanisms for those processes. "alg:none" lets you use the 
> > container without the crypto in a way that's compatible with using 
> > the same contianer with crypto. Code reuse and parallelism are 
> > awesome. But by explicitly calling out that a thing is unsigned, an 
> > app can decide whether or not it likes unsigned stuff and act
accordingly.
> > Plaintext JWSs haven't been free of controversy but the topic has 
> > been discussed many times and the [rough] consensus of the WG is that
the "none"
> > JWS alg is useful. It is in use by the finalized versions of OpenID 
> > Connect, as Vladimir has alluded to. And it has been fairly wildly 
> > deployed in production use.
> >
> > The "Plaintext JWS Security Considerations" in section 8.5 of JWA 
> > [1] represents the consensus the WG came to, which keeps the "none" 
> > alg but mandates that implementations "MUST NOT accept such objects 
> > as valid unless the application specifies that it is acceptable for a
specific object."
> >> Is there consensus in the WG that this is the right thing to do?  
> >> I'm expecting some push-back on this one and want to make sure it 
> >> has consensus behind it.  I have heard of a couple of objections
already.
> >> >> How would they be secured then?  With the current threat 
> >> >> landscape, it seems odd that we would be putting forth a method that
is not secured?
> >> > pointed out in the his response.
> >> >
> >> > JWT-encoded ID tokens in OpenID Connect is one such example, but 
> >> > only when the token is returned from the OAuth 2.0 token endpoint 
> >> > where TLS is mandatory, clients can then register to receive 
> >> > plaintext ID tokens:
> >> >
> >> > There is a section in the JWA spec to instruct developers of the 
> >> > various security considerations regarding use of "none" alg JWS:
> >> >
> >> >
> >> >> > > Section 3.6 - Can you explain why would this be included?  
> >> >> > > If you are
> >> >> > Perhaps the most popular application of JWS today is to 
> >> >> > construct JSON Web Tokens (JWT), such as the ID tokens in 
> >> >> > OpenID Connect. The JWT spec permits plain tokens that don't 
> >> >> > have a signature and this is enabled by the special case 
> >> >> > "none" alg in JWS.
> >> >> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 29 Apr 2014 14:26:28 -0400

Thank you, Jim, Vladimir & others.  The responses and insight was very
helpful to see how alg "none" is used and that it has been
implemented.

I read through the discussion and issue #36.  The last message,
http://www.ietf.org/mail-archive/web/jose/current/msg03586.html lets
me know how you got to this point.  Consensus was to remove alg none,
but it stayed in the draft because of implementations.

I do agree with the decision in the consensus statement, in favor of
removing alg none as that is cleaner from a design perspective.
Thanks to those who responded on this question with information on
implementation and use as this may get push back during the last call
process via SecDir and the IESG reviews.  The additional information
provided will be helpful to explain the current state.

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 Apr 2014 18:32:43 +0000

Kathleen - I'm confused by your statement that "Consensus was to remove alg none" because I am not aware of any such consensus.  Rather, the predominant number of working group participants were in favor of retaining this useful functionality.  That is reflected in Jim's decision to close issue #36 as "WON'T FIX" in http://www.ietf.org/mail-archive/web/jose/current/msg03586.html.  The functionality was intentionally retained - based on rough consensus of the working group that it is important.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, April 29, 2014 11:26 AM
To: Jim Schaad
Cc: [email-masked]; Vladimir Dzhuvinov
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Thank you, Jim, Vladimir & others.  The responses and insight was very helpful to see how alg "none" is used and that it has been implemented.

I read through the discussion and issue #36.  The last message, http://www.ietf.org/mail-archive/web/jose/current/msg03586.html lets me know how you got to this point.  Consensus was to remove alg none, but it stayed in the draft because of implementations.

I do agree with the decision in the consensus statement, in favor of removing alg none as that is cleaner from a design perspective.
Thanks to those who responded on this question with information on implementation and use as this may get push back during the last call process via SecDir and the IESG reviews.  The additional information provided will be helpful to explain the current state.

On Tue, Apr 29, 2014 at 2:02 PM, Jim Schaad <[email-masked]> wrote:
> Vladimir,
>
> I would be quick to point out that this distinction is true only for 
> the compact encoding.  It is not true for the JSON encoding where you 
> need to figure out from alg field what you are expecting as people can 
> give you things which are not so clear cut.  (A JSON object with alg 
> none and with a signature field for example.)
>
> Jim
>
>
> overall context of the JOSE (and JWT) specs -- there was a lot of discussion about that.
>
> Here I would like to add something that may not be immediately 
> apparent, but is important from a security perspective -- while "none" 
> alg JOSE objects are described in the JWS spec, they have a very 
> distinct structure from JWS and JWE objects -- they have only two 
> parts -- the JOSE header and the payload. This makes it relatively 
> simple and foolproof to distinguish a "none" alg message, without even having to inspect the JOSE header.
>
> to provide type safety -- PlainObject (alg none), JWSObject 
> (signature) and JWEObject (encrypted object). So "none" alg objects 
> are technically quite distinct from JWS objects, despite being described in the same spec.
>
> Regards,
>
> Vladimir
>
>> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#s
>> > e
>> > ction-8.5
>> >
>> > Vladimir
>> >> > Yes, securing the JWS message with TLS for instance, as Mike 
>> >> > just pointed out in the his response.
>> >> >
>> >> > only when the token is returned from the OAuth 2.0 token 
>> >> > endpoint where TLS is mandatory, clients can then register to 
>> >> > receive plaintext ID tokens:
>> >> >
>> >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-2
>> >> > 5
>> >> > #section-8.5
>> >> >
>> >> >
>> >> > Vladimir
>> >> >
>> >> >
>> >> >
>> >> >> > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19
>> >> >> > #
>> >> >> > section-6
>> >> >> >
>> >> >> >
>> >> >> > Vladimir
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Best regards,
>> >> >> Kathleen
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 Apr 2014 18:35:17 +0000

Actually, it is true for the JSON encoding.  The "alg":"none" case is the only one in which "signature":"" may occur in the JSON serialization - just like it is the only case in which an empty third segment may occur in the compact serialization.  Looking for "signature":"" is just as easy as looking for the empty third segment.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, April 29, 2014 11:03 AM
To: 'Vladimir Dzhuvinov'; 'Kathleen Moriarty'
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Vladimir,

I would be quick to point out that this distinction is true only for the compact encoding.  It is not true for the JSON encoding where you need to figure out from alg field what you are expecting as people can give you things which are not so clear cut.  (A JSON object with alg none and with a signature field for example.)

Jim

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Tuesday, April 29, 2014 7:56 AM
To: Kathleen Moriarty
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Hello Kathleen,

The utility of having JOSE-structured objects with protection provided at a higher level (e.g. TLS, as used in OpenID Connect) was generally understood and agreed. How to write this up and structure it in the overall context of the JOSE (and JWT) specs -- there was a lot of discussion about that.

Here I would like to add something that may not be immediately apparent, but is important from a security perspective -- while "none" alg JOSE objects are described in the JWS spec, they have a very distinct structure from JWS and JWE objects -- they have only two parts -- the JOSE header and the payload. This makes it relatively simple and foolproof to distinguish a "none" alg message, without even having to inspect the JOSE header.

Implementers can apply this distinction at code level too. The open source Nimbus JOSE+JWT library for example uses three separate classes to provide type safety -- PlainObject (alg none), JWSObject (signature) and JWEObject (encrypted object). So "none" alg objects are technically quite distinct from JWS objects, despite being described in the same spec.

Regards,

Vladimir

accordingly.
the "none"
specific object."
already.
is not secured?

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 29 Apr 2014 18:03:44 -0400

Hi Mike,

After reading through the threads, summaries provided from the interim
call, and issue tracker, the reason this was retained was because of
implementation work and not consensus.  I'm fine with keeping alg none
as the working group decision and will support that, but needed enough
background to be able to do so if this comes up in last call.

-- 

Best regards,
Kathleen