ietf
[Top] [All Lists]

RE: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

2015-12-16 19:00:01
Hey Richard,

See my reply to Robert and the language being added to the spec.  I believe 
that the text requiring "crit" in all situations other than when it adds no 
value should address the point you're making.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: Richard Barnes [mailto:rlb(_at_)ipv(_dot_)sx] 
Sent: Monday, December 14, 2015 5:23 PM
To: Robert Sparks <rjsparks(_at_)nostrum(_dot_)com>
Cc: Mike Jones <Michael(_dot_)Jones(_at_)microsoft(_dot_)com>; General Area 
Review Team <gen-art(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org; 
jose(_at_)ietf(_dot_)org; 
draft-ietf-jose-jws-signing-input-options(_at_)ietf(_dot_)org
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Hey Mike,

tl;dr: I agree "crit" needs to be required.

If I understand you correctly, you're observing that if the receiving 
implementation supports "b64":false, then there's no need for "crit":["b64"], 
so it's proper for the JWS to still verify.  That seems pretty tautological, 
given that the whole point of "crit" is to address implementations that *don't* 
support "b64".

This seems to hearken back to several debates we had in the initial JOSE round, 
where if you had some assumption outside the JOSE spec, then everything was OK. 
 As the SEC ADs pushed back at the time, so I'm pushing back now: The JOSE 
specs need to be themsleves internally consistent.  Yes, if you use "b64" 
without "crit" in a closed community where everyone supports "b64", then you'll 
be OK.  But that's not an interoperable behavior.  If one of these JWSs ever 
leaks
-- by error or malice -- then you're back in the case where you can have 
non-supporting recipients.

You could argue that the impact of interop failure isn't terrible here, because 
it fails closed -- it's unlikely that a signature over $CONTENT will verify 
with regard to base64($CONTENT).  I don't have a concrete attack scenario, but 
this seems to invite confused deputy problems of the same sort that arise in 
XML-DSIG.  Let's not go there.

--Richard


On Mon, Dec 14, 2015 at 11:11 AM, Robert Sparks 
<rjsparks(_at_)nostrum(_dot_)com> wrote:
Mike -

No, this still doesn't explain why crit is not sufficient.

You are making a bare assertion that using crit doesn't achieve a). I 
think it does. Please explain (in the draft) why it doesn't.

You are making me guess, but I think you are only trying to avoid 
having to include the few extra bits in the message. If you've _done_ 
the work of ensuring all the applications understand using b64 through 
some out-of-band magic, then including crit will just work. Are you 
pushing back on anything _but_ the packet-bloat in this case?

If you _haven't_ done this out-of-band work, and you send to a 
receiver that understands the extension, then a) is achieved. If you 
send to a receiver that doesn't understand, things _should_ fail - 
arguably this also achieving a), though I suspect you are wincing at 
perhaps not having a clear path to recovery in this case?

I really think this boils down to you not wanting to pay the extra few 
bits in the packet to say "crit".
if that's not the case, please explain (and again, this needs to be in 
the draft, not just an email thread).

RjS




On 12/13/15 10:04 PM, Mike Jones wrote:

Hi Robert,

You asked "_WHY_ is crit not sufficient? I think that's the thing 
that's missing as motivation."

There are two goals we're discussing, which are related:
(a) Having an application that uses "b64":false work.
(b) Having an application that receives a JWT with "b64":false not 
misinterpret the payload content.

Including "crit":["b64"] would be sufficient to achieve (b), as it 
would cause the JWS to be rejected by implementations not supporting 
"b64".  But it does not achieve (a), since the JWS would be rejected.

In contrast, using an implementation that understands "b64" achieves 
both
(a) and (b) without needing to include "crit".  That's why it's not 
required.

Does that make sense now?

                                Best wishes,
                                -- Mike

-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones <Michael(_dot_)Jones(_at_)microsoft(_dot_)com>; General Area 
Review 
Team <gen-art(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org; 
jose(_at_)ietf(_dot_)org; 
draft-ietf-jose-jws-signing-input-options(_at_)ietf(_dot_)org
Subject: Re: Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-06

Cutting away a bit to focus on the question:

On 12/12/15 8:32 PM, Mike Jones wrote:

Hi Robert.  Thanks for the useful review.  Replies are inline below...

-----Original Message-----

<snip/>


I would have been much more comfortable with a consensus to require 
'crit'.
(Count me in the rough if this proceeds with crit being optional).

I assume there is a strong reason to allow for option 1. Please add 
the motivation for it to the draft, and consider adding a SHOULD 
use 'crit'
requirement if option 1 remains.

It's a reasonable request to have the draft say why "crit" isn't 
required.  My working draft adds the following new paragraph at the 
end of the security considerations section to do this.  Unless I 
hear objections, I'll plan on publishing an updated draft with the 
paragraph shortly.

"Note that methods 2 and 3 are sufficient to cause JWSs using this 
extension to be rejected by implementations not supporting this 
extension but they are not sufficient to enable JWSs using this 
extension to be successfully used by applications.

The conclusion you draw here is not at all obvious.
_WHY_ is crit not sufficient? I think that's the thing that's missing 
as motivation.

   Thus, method 1 - requiring support for this extension - is the 
preferred approach and the only means for this extension to be 
practically useful to applications. Method 2 - requiring the use of 
<spanx style="verb">crit</spanx> - while theoretically useful to 
ensure that confusion between encoded and unencoded payloads cannot 
occur, is not particularly useful in practice, since method 1 is 
still required for the extension to be usable. When method 1 is 
employed, method 2 doesn't add any value and since it increases the 
size of the JWS, its use is not required by this specification."

Nits/editorial comments:

In the security considerations, the last sentence of the first 
paragraph needs to be simplified. I suggest replacing it with:

"It then becomes the responsibility of the application to ensure 
that payloads only contain characters that will not cause parsing 
problems for the serialization used, as described in Section 5. The 
application also incurs the responsibility to ensure that the 
payload will not be modified during retransmission.

I have simplified this in the manner that you suggested.

                                Thanks again,
                                -- Mike