Subject: [Gen-art] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Dec 2015 13:08:01 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-jose-jws-signing-input-options-06
Reviewer: Robert Sparks
Review Date: 4Dec2015
IETF LC End Date: 9Dec2015
IESG Telechat date: 17Dec2015

Summary: Almost ready for publication as Proposed Standard, but with a 
minor issue that should be addressed before publication.

Minor issues:

This document explicitly provides a way for interoperability to fail, 
but does not motivate _why_ leaving this failure mode in the protocol is 
a good tradeoff.

Specifically, as the security considerations section points out, it is 
possible for an existing implementation to receive a JWS that has 
b64=false, which it will ignore as an unknown parameter, and (however 
unlikely) successfully decode the payload, and hence believe it has a 
valid JWS that is not what was sent.

The idea that this failure can be avoided by making sure the endpoints 
all play nice through some unspecified agreement is dangerous. 
Specifically, I don't think you can rule out the case that the JWS 
escapes the controlled set of actors you are positing in option 1 from 
the list in the security considerations..

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.

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.

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Dec 2015 02:32:45 +0000

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

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Friday, December 4, 2015 11:08 AM
> To: General Area Review Team <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> This document explicitly provides a way for interoperability to fail, but does
> not motivate _why_ leaving this failure mode in the protocol is a good
> tradeoff.
> 
> Specifically, as the security considerations section points out, it is possible for
> an existing implementation to receive a JWS that has b64=false, which it will
> ignore as an unknown parameter, and (however
> unlikely) successfully decode the payload, and hence believe it has a valid
> JWS that is not what was sent.
> 
> The idea that this failure can be avoided by making sure the endpoints all
> play nice through some unspecified agreement is dangerous.
> Specifically, I don't think you can rule out the case that the JWS escapes the
> controlled set of actors you are positing in option 1 from the list in the
> security considerations..
> 
> 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).
> 

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. 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

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 12 Dec 2015 21:08:14 -0800

Mike,

I think that the text is somewhat tone deaf to the issue that Robert raises,
and which I have said many times.

The question is not how to I make sure it will work, but how do I make sure
that it will fail when it is not supposed to work.  Use of 'crit' does that
quite well.  It is not clear that your favored method 1 would do this.

Jim

> From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
> Sent: Saturday, December 12, 2015 6:33 PM
> To: Robert Sparks <[email-masked]>; General Area Review Team <gen-
> [email-masked]>; [email-masked]; [email-masked];
draft-ietf-jose-jws-signing-input-
> [email-masked]
> Subject: Re: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
> 06
> > Subject: Gen-Art LC review:
> > draft-ietf-jose-jws-signing-input-options-06
> >
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > but does not motivate _why_ leaving this failure mode in the protocol
> > is a good tradeoff.
> >
'crit'.
> > 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'
> 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. 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:
> >
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Dec 2015 05:24:37 +0000

Yes, you can make it fail if you're using library not supporting the extension by using "crit".  The spec already says that and the new paragraph goes into it further.  But using library not supporting functionality needed by the application seems like a pretty poor choice - all-up.  This is something that would be caught during debugging - well before production deployment.

If the application needs support for "b64":false to work correctly and doesn't have it, the application will be broken and is incorrect, no matter what, just like it would if it didn't have an implementation of RFC 7515 at all.  Yes, particular applications can send "crit":["b64"] if they want to guarantee a particular kind of failure if the recipient is incorrectly implemented but has a working implementation of RFC 7515, but that seems like a real corner case - nonetheless, one that is already covered in the specification, should applications want to achieve that.

I'm not aware of any cases that aren't already covered - especially once the new paragraph is added.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, December 12, 2015 9:08 PM
To: Mike Jones <[email-masked]>; 'Robert Sparks' <[email-masked]>; 'General Area Review Team' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike,

I think that the text is somewhat tone deaf to the issue that Robert raises, and which I have said many times.

The question is not how to I make sure it will work, but how do I make sure that it will fail when it is not supposed to work.  Use of 'crit' does that quite well.  It is not clear that your favored method 1 would do this.

Jim

> To: Robert Sparks <[email-masked]>; General Area Review Team 
> <gen- [email-masked]>; [email-masked]; [email-masked];
> > Summary: Almost ready for publication as Proposed Standard, but with 
> > a minor issue that should be addressed before publication.
> >
> > Minor issues:
> >
> > This document explicitly provides a way for interoperability to 
> > fail, but does not motivate _why_ leaving this failure mode in the 
> > protocol is a good tradeoff.
> >
> > Specifically, as the security considerations section points out, it 
> > is possible for an existing implementation to receive a JWS that has 
> > unlikely) successfully decode the payload, and hence believe it has 
> > a valid JWS that is not what was sent.
> >
> > The idea that this failure can be avoided by making sure the 
> > endpoints all play nice through some unspecified agreement is dangerous.
> > escapes the controlled set of actors you are positing in option 1 
> > from the list in the security considerations..
> >
'crit'.
'crit'
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
extension to
not
> sufficient to enable JWSs using this extension to be successfully used 
> by applications. Thus, method 1 - requiring support for this extension 
> - is
the
useful
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.
specification."
> > "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.
>

---

From: Robert Sparks <[email-masked]>
Date: Sun, 13 Dec 2015 15:11:29 -0600

Cutting away a bit to focus on the question:

>> -----Original Message-----
<snip/>
> "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:
>>

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Dec 2015 04:04:45 +0000

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:[email-masked]] 
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

<snip/>
>> the motivation for it to the draft, and consider adding a SHOULD use 'crit'
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.

>> 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.

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Dec 2015 07:16:59 +0000

These resolutions are now published in -07.  Thanks again!

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Sunday, December 13, 2015 8:05 PM
To: Robert Sparks <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Hi Robert,

				Best wishes,
				-- Mike 

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

<snip/>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Dec 2015 10:11:42 -0600

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 14 Dec 2015 11:22:34 -0500

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 <[email-masked]> wrote:
> 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
>
>
>
>
>> 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.
>>
>> To: Mike Jones <[email-masked]>; General Area Review Team
>> <[email-masked]>; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Re: Gen-Art LC review:
>>> 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.
>>>
>>> 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.
>>
>>>    Thus, method 1 - requiring support for this extension - is the
>>> useful to applications. Method 2 - requiring the use of <spanx
>>> 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:
>>>>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Dec 2015 13:42:16 -0800

Mike,

This is interesting from a couple of points.

Why would you have an application that uses "b64":false as a parameter.
This is longer and thus would appear to be undesirable from that
perspective.  It might imply that the application is using both true and
false for b64, but that is something that you have said is not recommended.

It would, of course, be perfectly acceptable to say that crit needs to be
present only if b64 is true.  This would address your worry about it failing
for the case of b64:false being included.

Jim

> 06
> 
> Hi Robert,
> 
> You asked "_WHY_ is crit not sufficient? I think that's the thing that's
missing as
> motivation."
> (b) Having an application that receives a JWT with "b64":false not
misinterpret
> the payload content.
cause the
> JWS to be rejected by implementations not supporting "b64".  But it does
not
> achieve (a), since the JWS would be rejected.
> 
(a)
> and (b) without needing to include "crit".  That's why it's not required.
> 
draft-ietf-jose-jws-signing-
> [email-masked]
'crit'.
'crit'
> > It's a reasonable request to have the draft say why "crit" isn't
required.  My
publishing
> > "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
> applications.
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:
> >>

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 00:58:18 +0000

Thanks for your thoughtful comments, Robert.  Replies are inline below...

> Sent: Monday, December 14, 2015 5:12 PM
> <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-jose-jws-signing-
> [email-masked]

I'll plan on adding something along these lines to the draft to explain this:

"Implementations receiving JWSs using "b64" with a value of "false" will not be able to successful use those JWSs unless they support this extension, since they will be unable to obtain the payload value.  If the JWS includes the "crit" Header Parameter with "b64" in the set of values, this will ensure that implementations not supporting this extension will reject the JWS, but including "crit" is insufficient to enable the receiving implementation to use the JWS; that requires supporting this extension."

> 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.
> 
> 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?
> 
> 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).

Yes, size matters, but that's not the primary thing that's in play here.  For the extension to be useful, all parties using the JWS must implement the extension, as explained in the new proposed text above.  And once the JWT with the extension is understood, "crit" adds nothing, because it's redundant.  That's why the draft doesn't require it.

But based on your comments and those of other reviewers, since there seems to be demand for it, I plan to add the following text, which I think gets at the heart of the issue you're discussing:

"Using "crit" with "b64"

If a JWS using "b64" with a value of "false" might be processed by implementations not implementing this extension, then the "crit" Header Parameter MUST be included with "b64" in its set of values to cause such implementations to reject the JWS.  Conversely, if used in environments in which all participants implement this extension, then "crit" need not be included, since its inclusion would have no effect, other than increasing the JWS size and processing costs."

> RjS

				Thanks again, Robert,
				-- Mike

> missing as motivation."
> 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.
> >
> (a) and (b) without needing to include "crit".  That's why it's not 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.
> >>
> >>    Thus, method 1 - requiring support for this extension - is the preferred
> 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:
> >>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 00:58:57 +0000

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:[email-masked]] 
Sent: Monday, December 14, 2015 5:23 PM
To: Robert Sparks <[email-masked]>
Cc: Mike Jones <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Hey Mike,

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 <[email-masked]> wrote:
> 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?
>
>> 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.
>>
>> To: Mike Jones <[email-masked]>; General Area Review 
>> Team <[email-masked]>; [email-masked]; [email-masked]; 
>>> 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.
>>>
>>> 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.
>>
>>> 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:
>>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 00:59:26 +0000

Hi Jim,

Please see my replies to Robert and Richard.  I believe they cover the point you're making below.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, December 14, 2015 10:42 PM
To: Mike Jones <[email-masked]>; 'Robert Sparks' <[email-masked]>; 'General Area Review Team' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike,

Why would you have an application that uses "b64":false as a parameter.
This is longer and thus would appear to be undesirable from that perspective.  It might imply that the application is using both true and false for b64, but that is something that you have said is not recommended.

It would, of course, be perfectly acceptable to say that crit needs to be present only if b64 is true.  This would address your worry about it failing for the case of b64:false being included.

Jim

missing as
misinterpret
> would
cause the
not
(a)
'crit'.
'crit'
required.  My
publishing
extension
are not
> by applications.
motivation.
preferred
> approach and the only means for this extension to be practically 
> while theoretically useful to ensure that confusion between encoded 
> and unencoded payloads cannot occur, is not particularly useful in 
> practice,
since
is
> size
of the

---

From: "Manger, James" <[email-masked]>
Date: Thu, 17 Dec 2015 13:07:54 +1100

Mike proposes the following:

   "Using "crit" with "b64"

"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is precisely the case where "crit" should be used (new messages that can be misunderstood by old implementations). If it isn't used here, I doubt it will ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author of the JWS spec defining "crit" is a sign that "crit" itself is a poor design for supporting extensibility. There were alternative versioning mechanisms discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values to ensure the JWS is rejected (instead of being misinterpreted) by implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is another mechanism to prevent misinterpretation, such as another "crit" value that also implies "b64" understanding, or the elimination of all old implementations.

Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not be able to successful use those JWSs unless they support this extension, since they will be unable to obtain the payload value.  ... including "crit" is insufficient to enable the receiving implementation to use the JWS; that requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if "successful" means from the senders point of view) or wrong (as the recipient thinks they have been successful when they have actually misinterpreted the message).

Please remove method 3: sending a payload with non-base64url chars. This makes too many assumptions about how a base64url-decoder will handle unexpected chars. Some will reject anything outside A-Za-z0-9-_, others will ignore whitespace, others will happily decode +/ and -_, others will ignore =, perhaps others ignore any unexpected chars.

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 03:52:29 +0000

James, as I see it, your proposal optimizes the Header Parameter requirements for the case in which the JWS isn't useful, rather than case in which it is.  This seems backwards, from an engineering point of view.

The new "crit" language in -08 already ensures clean failure in all the cases in which failure should occur.  There's then no need to include an extra parameter intended to cause a failure in cases in which the failure cannot occur.

				-- Mike

-----Original Message-----
From: Manger, James [mailto:[email-masked]] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones <[email-masked]>; Robert Sparks <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; Ben Campbell <[email-masked]>; Benoit Claise <[email-masked]>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

   "Using "crit" with "b64"

Please don't add:

--
James Manger

---

From: "Manger, James" <[email-masked]>
Date: Thu, 17 Dec 2015 15:34:57 +1100

Mike,

draft-ietf-jose-jws-signing-input-options-08 says:

   if used in environments in which all participants implement this extension, then "crit" need not be included

The clash here is whether such "environments" are reality, and if they are the audience of this IETF spec.
This sentence implies environment-specific JWS code, which rather goes against the point of a generic spec.

--
James Manger

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, 17 December 2015 2:52 PM
To: Manger, James <[email-masked]>; Robert Sparks <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; Ben Campbell <[email-masked]>; Benoit Claise <[email-masked]>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

				-- Mike

-----Original Message-----
From: Manger, James [mailto:[email-masked]] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones <[email-masked]>; Robert Sparks <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; Ben Campbell <[email-masked]>; Benoit Claise <[email-masked]>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

   "Using "crit" with "b64"

Please don't add:

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Dec 2015 16:15:07 +0000

FYI, Robert, "crit" is now required with "b64", as you'd requested.

-----Original Message-----
From: Mike Jones 
Sent: Wednesday, December 16, 2015 4:58 PM
To: 'Robert Sparks' <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

> draft-ietf-jose-jws-signing- [email-masked]

> some out-of- band magic, then including crit will just work. Are you 

"Using "crit" with "b64"

				Thanks again, Robert,
				-- Mike

> > would cause
> the JWS to be rejected by implementations not supporting "b64".  But 
> Team
> >>> 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'
> 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:
> >>>
> >>> problems for the serialization used, as described in Section 5. 
> >>> The application also incurs the responsibility to ensure that the