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

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Tue, 20 Aug 2013 07:27:40 -0700

Hi guys,

In this heated discussion I find it hard to see any actual opposing
arguments :)

People generally agree that plain (unprotected) JOSE objects have their
legitimate use, e.g. in OpenID Connect request objects.

If there's some confusion, that's perhaps because we have the
unprotected JOSE objects defined in the JWS spec, instead in a spec of
its own, e.g. "JSON Web Header" or "JSON Web Object".

The Nimbus JOSE+JWT library enforces this distinction at the class
level, by having separate classes for plain, JWS and JWE objects, and
there have been only positive feedback from developers on this. The
class hierarchy looks like this:

abstract class JOSEObject
PlainObject extends JOSEObject
JWSObject extends JOSEObject
JWEObject extends JOSEObject

I understand that there can be several approaches to parsing and
switching JOSE messages, be it top-level base64url segment counting
and/or alg parsing. But even if parsing is sloppily implemented and a
plain object is fed into a JWS parser, that would soon cause further
processing to fail due to the missing signature segment.

For software that only needs to route the messages without validating
them, a simple examination of the dot delimiters and the surrounding
base64url segments is sufficient, as people have pointed out.

The third dot in plain objects is probably an remnant that we have from
the spec or other association with JWSs, but that minor inefficiency is
not a deal breaker for us.

If there's mood in the WG to move plain objects into a simple separate
spec I will support that. The general structuring of the JOSE objects
however looks very good to me and I think the WG has done a good job
with it so far.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[email-masked]>
wrote:
   On 08/19/2013 04:17 PM, Richard Barnes wrote:
  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.
 
 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".  

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>

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. 

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.

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

I am too, but from the opposite end -- why is it so important for you to
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 

  -- Justin

 

 John B.
  
 On 2013-08-19, at 12:30 PM, Justin Richer <[email-masked]> wrote:
 
 > 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
 >
 > On 08/01/2013 07:23 AM, jose issue tracker wrote:
 >> #36: Algorithm "none" should be removed
 >>
 >>
 >> 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!

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

 

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

---

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Thu, 22 Aug 2013 08:30:58 -0700

I also think giving plain JOSE objects their own document, apart from
the JWS spec, will make it easier for developers to understand the
matter and get their implementations (libraries) as we intend, and thus
save them from possible confusion.

The other day a developer filed a bug report, which eventually got
tagged as won't fix, that is symptomatic of the issue:

https://bitbucket.org/nimbusds/nimbus-jose-jwt/issue/58/make-none-a-valid-jws-alg-type

Here I wish to clarify that what I support is an editorial change that
will not affect implementations, save for specifying a new MIME type
header for the plain objects.

Mike, you are the editor of the whole spec suite and know the texts,
their structuring and how they're linked together probably better than
any one of us. Do you see an elegant workable path to have all plain
JOSE related stuff moved into a document of its own? Are there any
IETF-related implications to that, which could pose a problem?

Today I went through the latest versions of the JOSE specs. The JWS has
no mention of unprotected JWSs in the main body, only in Appendix 5 (the
examples). The JWA spec mentions "none" only in section 3.1 (the alg
table) and section 3.6. It so appears that the changes that will have to
made will be relatively localised. 

Having reread the specs it now looks like the WG has produced some
really useful, well defined and structured documents. The only bit that
feels awkward and difficult to explain to readers is having that JWS alg
"none". We have the JWS spec claim, in the opening sentence of the
abstract, that it is "means of representing content secured with digital
signatures or Message Authentication Codes (MACs)" and then mention
later that a JWS may actually also be unprotected. Which, logically
speaking, goes against all claims that the JWS spec makes in its
abstract and also in various places in the terminology section.

Vladimir

-------- Original Message --------
Subject: Re: [jose] #36: Algorithm "none" should be removed
From: Richard Barnes <[email-masked]>
Date: Thu, August 22, 2013 5:32 am
To: "Manger, James H" <[email-masked]>
Cc: Mike Jones <[email-masked]>, jose issue tracker
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>

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