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 protected]]
Sent: Thursday, August 01, 2013 5:31 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker;
<[email protected]>; <[email protected]>
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 protected]<mailto:[email protected]>> 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
From: Richard Barnes [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, August 01, 2013 5:20 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker;
<[email protected]<mailto:[email protected]>>;
<[email protected]<mailto:[email protected]>>
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:
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 protected]<mailto:[email protected]>> wrote:
That would require special parsing. "alg":"none" doesn't.
From: Richard Barnes [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, August 01, 2013 5:03 AM
To: Matt Miller (mamille2)
Cc: jose issue tracker;
<[email protected]<mailto:[email protected]>>;
Mike Jones; <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> 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
Matt Miller < [email protected]<mailto:[email protected]> >
Cisco Systems, Inc.
On Aug 1, 2013, at 1:23 PM, jose issue tracker
<[email protected]<mailto:trac%[email protected]>> wrote:
> #36: Algorithm "none" should be removed
>
>
> Comment (by [email protected]<mailto:[email protected]>):
>
> 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!
>
> --
> -------------------------+-------------------------------------------------
> Reporter: | Owner: draft-ietf-jose-json-web-
> [email protected]<mailto:[email protected]> |
> [email protected]<mailto:[email protected]>
> 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:4>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
