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

[Mike Jones]

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' ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.org
Subject: RE: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

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

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Monday, December 14, 2015 5:12 PM
> To: Mike Jones ; General Area Review Team 
> ; i...@ietf.org; j...@ietf.org; 
> draft-ietf-jose-jws-signing- input-opti...@ietf.org
> Subject: Re: Gen-Art LC review: 
> draft-ietf-jose-jws-signing-input-options-06
> 
> Mike -
> 
> No, this still doesn't explain why crit is not sufficient.

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

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

> 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:rjspa...@nostrum.com]
> > Sent: Sunday, December 13, 2015 1:11 PM
> > To: Mike Jones ; General Area Review
> Team
> > ; i...@ietf.org; j...@ietf.org; 
> > draft-ietf-jose-jws-signing-input-opti...@ietf.org
> > 

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

[Mike Jones]

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

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Monday, December 14, 2015 5:12 PM
> To: Mike Jones ; General Area Review Team
> ; i...@ietf.org; j...@ietf.org; draft-ietf-jose-jws-signing-
> input-opti...@ietf.org
> Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
> 
> Mike -
> 
> No, this still doesn't explain why crit is not sufficient.

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

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

> 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:rjspa...@nostrum.com]
> > Sent: Sunday, December 13, 2015 1:11 PM
> > To: Mike Jones ; General Area Review
> Team
> > ; i...@ietf.org; j...@ietf.org;
> > draft-ietf-jose-jws-signing-input-opti...@ietf.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-
> > 
> >>>
> >>> I would have been much more comfortable with a consensus to require
> 'crit'.
> >>> (Count me in the rough if this proceeds 

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

[Mike Jones]

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:r...@ipv.sx] 
Sent: Monday, December 14, 2015 5:23 PM
To: Robert Sparks 
Cc: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.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  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:rjspa...@nostrum.com]
>> Sent: Sunday, December 13, 2015 1:11 PM
>> To: Mike Jones ; General Area Review 
>> Team ; i...@ietf.org; j...@ietf.org; 
>> draft-ietf-jose-jws-signing-input-opti...@ietf.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-
>>
>> 


 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 

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

[Robert Sparks]

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:rjspa...@nostrum.com]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.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-




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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Mike Jones]

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:rjspa...@nostrum.com] 
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.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-

>>
>>
>> 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  style="verb">crit - 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Robert Sparks]

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-





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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Mike Jones]

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

-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Sunday, December 13, 2015 8:05 PM
To: Robert Sparks ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.org
Subject: RE: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

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:rjspa...@nostrum.com]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.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-

>>
>>
>> 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  style="verb">crit - 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Mike Jones]

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

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Friday, December 4, 2015 11:08 AM
> To: General Area Review Team ; i...@ietf.org;
> j...@ietf.org; draft-ietf-jose-jws-signing-input-opti...@ietf.org
> 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.
> 
> For more information, please see the FAQ at
> 
> .
> 
> 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.

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 crit - 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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art