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 protected]]
Sent: Tuesday, August 20, 2013 7:33 AM
To: George Fletcher
Cc: Justin Richer; John Bradley; Mike Jones; jose issue tracker; [email protected];
[email protected]
Subject: Re: [jose] #36: Algorithm "none" should be removed
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.
On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher
<[email protected]<mailto:[email protected]>> wrote:
On 8/20/13 9:49 AM, Justin Richer wrote:
On 08/19/2013 05:46 PM, Richard Barnes 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.
I realize I missed the call last night so maybe this is all mute:)
Thanks,
George
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
