Subject: [secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Dec 2015 13:04:47 -0500 (EST)

Hi all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document is Ready.

The main JWS spec (RFC 7515) required that the signed payload was
base64url-encoded prior to signing.  This results in a noticeable size
expansion; in some circumstances it is desirable to avoid this expansion
and reencoding.  I did not follow the JWS document closely at the time,
but I believe this issue was raised at the time and consensus reached on
the published version because it is always safe for applications to use.
This document provides an opt-in mechanism for application (protocol)s to
avoid the extra encoding and expansion, leaving the burden on the
application to determine whether it is safe to do so and perform the
relevant input checking/sanitization.  The security considerations
correctly describe the implications of the loss of encoding and the
restrictions on the signed content when detached payloads are not used,
interoperability concerns for applications not supporting the b64 header
parameter, and proposes appropriate countermeasures.

Interestingly, this document does not need to update the JWS spec, since
it is just adding to an IANA registry and not modifying the core spec, but
it does update the JWT spec (RFC 7519) to prohibit the use of b64=false in
JWTs.  No justification is made for this restriction in the text of the
document, but it seems reasonable to "play it safe" in this sense, to me.

I do have a few nits unrelated to the security review:

The abstract mentions the "Updates: 7519", but the introduction does not;
I am sometimes told that both locations should mention the update, but I
assume that the RFC Editor will notice if anything needs to change.

It is a bit amusing that the example with payload "$.02" is actually
longer with the unencoded payload, due to the overhead of the header
field, but I do not suggest modifying the example at this time.

Section 5.3 makes reference to Section 8.3 of RFC 7159 for JSON
string-escape processing, but I think perhaps section 7 of that RFC would
be a better reference.

Relatedly, I needed to reread the text in Section 5.3 a few times in order
to convince myself that I correctly understood the procedure for
generating the payload to be signed, but I believe that all the steps
given are necessary and correct, and do not have proposed text that would
be better.  String-escape processing is just inherently fiddly.

I did not attempt to verify the examples' encoding and consistency.

Thanks for this well-written document.

-Ben

---

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

Hi Ben,

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

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Friday, December 11, 2015 10:05 AM
> To: [email-masked]; [email-masked]; draft-ietf-jose-jws-signing-input-
> [email-masked]
> Subject: secdir review of draft-ietf-jose-jws-signing-input-options-06
> 
> Hi all,
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> This document is Ready.
> 
> expansion; in some circumstances it is desirable to avoid this expansion and
> reencoding.  I did not follow the JWS document closely at the time, but I
> believe this issue was raised at the time and consensus reached on the
> published version because it is always safe for applications to use.
> application to determine whether it is safe to do so and perform the relevant
> input checking/sanitization.  The security considerations correctly describe
> the implications of the loss of encoding and the restrictions on the signed
> content when detached payloads are not used, interoperability concerns for
> applications not supporting the b64 header parameter, and proposes
> appropriate countermeasures.

Thanks for letting us know that the security considerations were clear.

> Interestingly, this document does not need to update the JWS spec, since it is
> just adding to an IANA registry and not modifying the core spec, but it does
> update the JWT spec (RFC 7519) to prohibit the use of b64=false in JWTs.  No
> justification is made for this restriction in the text of the document, but it
> seems reasonable to "play it safe" in this sense, to me.

The restriction is there for interoperability reasons.  I added the phrase "For interoperability reasons" to my working copy of the document so this reason is stated.

> The abstract mentions the "Updates: 7519", but the introduction does not; I
> am sometimes told that both locations should mention the update, but I

The restriction is listed (and now motivated!) in the "Intended Use by Applications" section.  That being said, if the RFC editor wants it repeated elsewhere, that would be fine.

> It is a bit amusing that the example with payload "$.02" is actually longer
> with the unencoded payload, due to the overhead of the header field, but I
> do not suggest modifying the example at this time.

Yep - that is amusing.  I hadn't realized that, but it makes sense.

> Section 5.3 makes reference to Section 8.3 of RFC 7159 for JSON string-escape
> processing, but I think perhaps section 7 of that RFC would be a better
> reference.

The language you're referring to is actually directly copied from Section 5.3 of JWS [RFC 7519] because it's intended to have exactly the same meaning.  For consistency reasons between this spec and JWS, I'm reluctant to change the reference, even though I understand your point.

> Relatedly, I needed to reread the text in Section 5.3 a few times in order to
> convince myself that I correctly understood the procedure for generating the
> payload to be signed, but I believe that all the steps given are necessary and
> correct, and do not have proposed text that would be better.  String-escape
> processing is just inherently fiddly.

Again, because this language is from an already approved RFC and since you believe it is correct, I'm reluctant to fiddle with it.

> I did not attempt to verify the examples' encoding and consistency.

Others have done so (and are thanked in the Acknowledgements).

> Thanks for this well-written document.

Thanks for the useful review!  Unless I hear objections to these resolutions and those to Robert's Gen-ART review, I'll plan to publish the updated document shortly.

> -Ben

				Best wishes,
				-- Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 12 Dec 2015 22:28:29 -0500

Sent from my iPhone

> On Dec 12, 2015, at 9:33 PM, Mike Jones <[email-masked]> wrote:
> 
> Hi Ben,
> 
I think Ben is correct on this.  I'll check tomorrow and get back to you donut can be included in your update to save ADs time during their reviews.

Thanks for the review Ben!

Kathleen

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Dec 2015 03:30:46 +0000

Sounds good.  Thanks, Kathleen.

				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Saturday, December 12, 2015 7:28 PM
To: Mike Jones <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-jose-jws-signing-input-options-06

Sent from my iPhone

>> Subject: secdir review of 
>> draft-ietf-jose-jws-signing-input-options-06
>> 
>> Hi all,
>> 
>> base64url-encoded prior to signing.  This results in a noticeable 
>> size expansion; in some circumstances it is desirable to avoid this 
>> expansion and reencoding.  I did not follow the JWS document closely 
>> at the time, but I believe this issue was raised at the time and 
>> consensus reached on the published version because it is always safe for applications to use.
>> This document provides an opt-in mechanism for application 
>> (protocol)s to avoid the extra encoding and expansion, leaving the 
>> burden on the application to determine whether it is safe to do so 
>> and perform the relevant input checking/sanitization.  The security 
>> considerations correctly describe the implications of the loss of 
>> encoding and the restrictions on the signed content when detached 
>> payloads are not used, interoperability concerns for applications not 
>> supporting the b64 header parameter, and proposes appropriate countermeasures.
> 
>> Interestingly, this document does not need to update the JWS spec, 
>> since it is just adding to an IANA registry and not modifying the 
>> core spec, but it does update the JWT spec (RFC 7519) to prohibit the 
>> use of b64=false in JWTs.  No justification is made for this 
>> restriction in the text of the document, but it seems reasonable to "play it safe" in this sense, to me.
> 
>> The abstract mentions the "Updates: 7519", but the introduction does 
>> not; I am sometimes told that both locations should mention the 
>> update, but I assume that the RFC Editor will notice if anything needs to change.
> 

Kathleen 
>> string-escape processing, but I think perhaps section 7 of that RFC 
>> would be a better reference.
> 
>> Relatedly, I needed to reread the text in Section 5.3 a few times in 
>> order to convince myself that I correctly understood the procedure 
>> for generating the payload to be signed, but I believe that all the 
>> steps given are necessary and correct, and do not have proposed text 
>> that would be better.  String-escape processing is just inherently fiddly.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 13 Dec 2015 22:05:56 -0500

Mike,

Please do add that to the abstract and post as soon as you can with
all updates from last call received so far and agreed upon.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 13 Dec 2015 22:05:54 -0500 (EST)

Hi Mike,

Thanks for the explanations -- your proposed changes sound good to me.

-Ben

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 13 Dec 2015 22:37:16 -0500

Mike,

Sorry, I take that back.  The chairs make a good point in the shepherd
writeup.  This really doesn't update 7519, so it should not say that
in the abstract.

Thanks.

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Dec 2015 03:50:20 +0000

To confirm, you want me to remove the Updates 7519 clause, and the second paragraph of the abstract, which says:

   This specification updates RFC 7519 by prohibiting the use of the
   unencoded payload option in JSON Web Tokens (JWTs).

Correct?  I'll do that then shortly.

				Thanks,
				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Sunday, December 13, 2015 7:37 PM
To: Mike Jones <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-jose-jws-signing-input-options-06

Mike,

Sorry, I take that back.  The chairs make a good point in the shepherd writeup.  This really doesn't update 7519, so it should not say that in the abstract.

Thanks.

On Sun, Dec 13, 2015 at 10:05 PM, Kathleen Moriarty <[email-masked]> wrote:
>> Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; 
>> [email-masked]
>> Subject: Re: secdir review of 
>>>> security area directors.  Document editors and WG chairs should 
>>>> treat these comments just like any other last call comments.
>>>>
>>>> This document is Ready.
>>>>
>>>> expansion and reencoding.  I did not follow the JWS document 
>>>> closely at the time, but I believe this issue was raised at the 
>>>> time and consensus reached on the published version because it is always safe for applications to use.
>>>> payloads are not used, interoperability concerns for applications 
>>>> not supporting the b64 header parameter, and proposes appropriate countermeasures.
>>>
>>>> core spec, but it does update the JWT spec (RFC 7519) to prohibit 
>>>> the use of b64=false in JWTs.  No justification is made for this 
>>>> The abstract mentions the "Updates: 7519", but the introduction 
>>>> does not; I am sometimes told that both locations should mention 
>>>> the update, but I assume that the RFC Editor will notice if anything needs to change.
>>>
>>>> It is a bit amusing that the example with payload "$.02" is 
>>>> actually longer with the unencoded payload, due to the overhead of 
>>>> the header field, but I do not suggest modifying the example at this time.
>>>
>>>> Relatedly, I needed to reread the text in Section 5.3 a few times 
>>>> in order to convince myself that I correctly understood the 
>>>> procedure for generating the payload to be signed, but I believe 
>>>> that all the steps given are necessary and correct, and do not have 
>>>> proposed text that would be better.  String-escape processing is just inherently fiddly.
>>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 13 Dec 2015 22:58:47 -0500

Jim & Karen,

I see the updates in the last 2 versions in both the header and
abstract, prior to when the shepherd report was posted.  I see in the
shepherd report that you do not agree that this draft updates RFC7519.
Is there a reason this change was not already made to the draft?
Please confirm that removing this is the right action, it seems to be
from your shepherd report reasoning.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 13 Dec 2015 20:14:38 -0800

Please note that the write up addresses two different updates.

7519  which was in the document and updates JWT with the statement that says - don't do this
7515  which would be an update of JWS - however it was determined that updating the registry is sufficient without updating the document itself.

While I don't know that there is a need to update 7519 - there is not really a strong statement to be made either way, so I did not ask for it to be removed.  I was more worried about the question of having an update to 7515 which was not present. Karen and I determined that we probably did not need to have this document updated so there were no changes to be made to the document.

I would keep the 7519 update since that was seen by the WG.  And not put in an update to 7515 since, again, that was what the WG saw.

Jim

> Sent: Sunday, December 13, 2015 7:59 PM
> To: Mike Jones <[email-masked]>; [email-masked]
> Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; draft-
> [email-masked]
> I see the updates in the last 2 versions in both the header and abstract, prior to
> when the shepherd report was posted.  I see in the shepherd report that you do
> not agree that this draft updates RFC7519.
> Please confirm that removing this is the right action, it seems to be from your
> shepherd report reasoning.
> 
> Best regards,
> Kathleen
> 
> On Sun, Dec 13, 2015 at 10:50 PM, Mike Jones <[email-masked]>
> wrote:
> > Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked];
> > Sorry, I take that back.  The chairs make a good point in the shepherd writeup.
> This really doesn't update 7519, so it should not say that in the abstract.
> >
> > Thanks.
> >
> >>>>> I have reviewed this document as part of the security
> >>>>> directorate's ongoing effort to review all IETF documents being
> >>>>> processed by the IESG.  These comments were written primarily for
> >>>>> the benefit of the security area directors.  Document editors and
> >>>>> WG chairs should treat these comments just like any other last call
> comments.
> >>>>>
> >>>>> This document is Ready.
> >>>>>
> >>>>> size expansion; in some circumstances it is desirable to avoid
> >>>>> this expansion and reencoding.  I did not follow the JWS document
> >>>>> and perform the relevant input checking/sanitization.  The
> >>>>> security considerations correctly describe the implications of the
> >>>>> loss of encoding and the restrictions on the signed content when
> >>>>> detached payloads are not used, interoperability concerns for
> >>>> Thanks for letting us know that the security considerations were
> >>>> clear=

---

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

Kathleen - do you now concur with Jim that we should leave the Updates clause for 7519 in?  Let me know and then I'll post the resolutions to the Gen-Art and Sec-Dir comments.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Sunday, December 13, 2015 8:15 PM
To: 'Kathleen Moriarty' <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]
Cc: 'Benjamin Kaduk' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-jose-jws-signing-input-options-06

Jim

> draft- [email-masked]
> > To confirm, you want me to remove the Updates 7519 clause, and the 
> > second
> paragraph of the abstract, which says:
> >
> >>>> On Dec 12, 2015, at 9:33 PM, Mike Jones 
> >>>>> processed by the IESG.  These comments were written primarily 
> >>>>> for the benefit of the security area directors.  Document 
> >>>>> editors and WG chairs should treat these comments just like any 
> >>>>> other last call
> comments.
> >>>>>
> >>>>> This document is Ready.
> >>>>>
> >>>>> The main JWS spec (RFC 7515) required that the signed payload 
> >>>>> was base64url-encoded prior to signing.  This results in a 
> >>>>> noticeable size expansion; in some circumstances it is desirable 
> >>>>> to avoid this expansion and reencoding.  I did not follow the 
> >>>>> JWS document closely at the time, but I believe this issue was 
> >>>>> raised at the time and consensus reached on the published 
> >>>>> version because it is always
> safe for applications to use.
> >>>>> (protocol)s to avoid the extra encoding and expansion, leaving 
> >>>>> the burden on the application to determine whether it is safe to 
> >>>>> do so and perform the relevant input checking/sanitization.  The 
> >>>>> security considerations correctly describe the implications of 
> >>>>> the loss of encoding and the restrictions on the signed content 
> >>>>> when detached payloads are not used, interoperability concerns 
> >>>>> for applications not supporting the b64 header parameter, and 
> >>>>> proposes

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 14 Dec 2015 00:15:52 -0500

Sent from my iPhone

> On Dec 13, 2015, at 11:34 PM, Mike Jones <[email-masked]> wrote:
> 

Yes, that's fine.  Thanks, Jim.

Kathleen

---

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

Done in -07.

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Sunday, December 13, 2015 9:16 PM
To: Mike Jones <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-jose-jws-signing-input-options-06

Sent from my iPhone

Kathleen 
> To: 'Kathleen Moriarty' <[email-masked]>; Mike Jones 
> <[email-masked]>; [email-masked]
> Cc: 'Benjamin Kaduk' <[email-masked]>; [email-masked]; [email-masked]; 
> Subject: RE: secdir review of