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:
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
