Draft -04 now contains security considerations text addressing the confusion
about whether the payload is encoded or not that can be created by an attacker
under some circumstances, as well as calling out cases in which there is no
security problem.
Thanks again for your thoughtful reading of the draft.
-- Mike
From: Manger, James [mailto:[email protected]]
Sent: Wednesday, November 04, 2015 4:20 PM
To: Mike Jones; Jim Schaad; [email protected]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments
Mike,
draft-ietf-jose-jws-signing-input-options section 6 "Intended Use by
Applications" feels a bit silly. If "b64" is "not intended to be dynamically
varied with different payloads" then why are we making it a per-message field?
If an "application context" needs to pick either JWS-without-b64 or
JWS-with-b64-false, but never both, then don't let "JWS" be a name than
encompasses both - because that is the name apps will use.
"Application context" is itself a dodgy concept here. The point of
standardizing JWS is that it works the same regardless of context (so a common
library can be used in many contexts). Of course a new feature (like unencoded
payloads) can break old apps, but the new feature mustn't silently succeed with
the wrong semantics.
The very least (and it isn't nearly enough) there need to be another Security
Considerations paragraph:
A JWS using these signing options can be successfully verified but give the
wrong payload if it is ever consumed by a JWS implementation that does not
understand these options. Consequently, these options MUST only be used when
the signer can guarantee that every possible legitimate verifier has
implemented this specification.
--
James Manger
From: Mike Jones [mailto:[email protected]]
Sent: Tuesday, 3 November 2015 11:39 AM
To: Jim Schaad <[email protected]<mailto:[email protected]>>; Manger,
James
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments
You're right Jim, that my "prohibited" language below was too strong. The
proposed language on when "crit" is needed below will handle the case where the
application decides to ignore the intended usage and dynamically switch between
JWS objects with both "b64":true and "b64":false.
-- Mike
From: Jim Schaad [mailto:[email protected]]
Sent: Monday, November 02, 2015 8:36 PM
To: Mike Jones; 'Manger, James'; [email protected]<mailto:[email protected]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments
From: Mike Jones [mailto:[email protected]]
Sent: Monday, November 02, 2015 6:23 PM
To: Manger, James
<[email protected]<mailto:[email protected]>>; Jim
Schaad <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments
Thanks for your note and for thinking this through, James. Your comments were
useful and made me think, as always. As I see it, there are several cases to
consider.
If the producer implements the extension correctly, then as I wrote on the
21st, if the consumer doesn't understand it, then the signature will fail.
That's the case I was writing about earlier
So the case you're describing has to instead be one in which the producer is an
attacker and intentionally not implementing the extension correctly. In that
case, example you give is possible if the receiver doesn't understand the
extension. I used to be concerned about this but now I'm not. Here are two
reasons why:
1. The recipient is implementing an application that uses JWS - one property
of which is a specification by the application of whether the extension is used
or not. If the application uses the extension, then a correctly implemented
application client will implement the extension. In that case, if the attacker
uses "b64":false but signs as if "b64" were true (your described attack), then
the signature verification will fail. Whereas, if you start with the premise
that the recipient incorrectly implements the application, which your attack
requires, then all bets are off in the first place.
2. The recipient is already making a trust decision dictated by the
application's rules for using JWS about whether to trust the sender based on
verifying its signature and therefore its identity within the application
context. If the sender is actually an attacker and yet trusted by the
recipient once its signature is verified, the recipient has bigger problems
than the possibility of the sender being able to generate the same signature
for both encoded and unencoded values. If the sender is an attacker trusted by
the recipient, there are likely much worse ways for the sender to trick the
recipient, for instance, by signing maliciously generated content, which the
recipient then uses.
Only if the application dynamically switches between b64:false and b64:true
(something prohibited in
https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03#section-6),
would it be necessary for the application to require the use of
"crit":["b64"]. That would cause incorrectly implemented application clients
to nonetheless reject content signed with b64:false when it doesn't implement
"b64".
[JLS] I would disagree that this is prohibited in the section referred to. The
text says "it is intended" this is not that say as saying you MUST only use one.
I will add the thoughts above to the Security Considerations section.
And similarly to argument 1 above, if the application specifies the use of
b46:false with the compact serialization *and* the application will use
non-baseurl-safe payload characters such as comma, then it already has to be
prepared to accurately communicate those characters within the application
context. There is no backwards compatibility problem for existing applications
- only new options for new applications, if they choose to use the option. If
the existence of the extension would break any existing applications or require
any actions upon their part, then I would agree that this spec should be marked
as updating RFC 7515. But as it is, it's just a spec using the IANA registry
to register a new header parameter value. We certainly don't want to set the
precedent that every new header parameter registration will also require
updating RFC 7515.
Jim, I believe that the thoughts above also address the two questions in your
October 18th note in the same thread. Please let me know if you disagree.
-- Mike
From: Manger, James [mailto:[email protected]]
Sent: Thursday, October 22, 2015 9:32 AM
To: Jim Schaad; Mike Jones; [email protected]<mailto:[email protected]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments
Unfortunately Mike, the signature validation will not fail. By design
draft-ietf-jose-jws-signing-input-options mimics RFC7515 in using "bytes before
the 2nd dot" as the bytes to sign/verify. Consider a signer choosing the
b64=false option from draft-ietf-jose-jws-signing-input-options to sign the
12-byte message "IOU_5000_USD". The header is {"alg":"HS256","b64":false}
giving the JWS:
eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2V9.IOU_5000_USD.xxxxxxxxxxxxxxxxxxxxxxxx
A verifier that only understands RFC7515 JWS interprets this as a normal JWS
with an unknown but ignorable header member. The signature is still over
eyJ..USD so it still verifies. The verifier then base64url-decodes the IOU..
part to get the validly-signed 9-byte content (in hex) 20 E5 3F E7 4D 34 FD 44
83.
Ouch! One JWS can be interpreted as a signed 12-byte or 9-byte message.
One fix might be to make the b64=false signing input:
BASE64URL(UTF8(JWS Protected Header)) || '..' || JWS Payload
The two dots ensure the bytes signed when b64=false can never look like bytes
signed according to RFC7515.
draft-ietf-jose-jws-signing-input-options should probably do this in addition
to setting the crit field (so you can get a meaningful error message of
"unsupported variety of JWS", instead of "signature failure" that could have
all sorts of causes).
>From RFC7515 JWS, it would be perfectly reasonable to store a collection of
>compact-serialized-JWSs as comma-separated values - since a RFC7515
>compact-serialized-JWS cannot contain a comma.
>draft-ietf-jose-jws-signing-input-options breaks that perfectly reasonable
>choice as now an unencoded non-detached JWS can have any bytes and still be
>called a compact-serialized-JWS. Saying
>draft-ietf-jose-jws-signing-input-options updates RFC7515 is the minimum
>required to note this, though that isn't really adequate. A better solution is
>to not allow an unencoded non-detached message to be called a
>compact-serialized-JWS: either don't define this combination, or call it
>something else (eg JWS raw serialization).
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
