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

[Benjamin Kaduk <[e-mail]>]

Hi Mike,

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

-Ben

On Sat, 12 Dec 2015, Mike Jones wrote:

> Hi Ben,
>
> Thanks for the useful review.  Replies are inline below...
>
> > -----Original Message-----
> > From: Benjamin Kaduk [mailto:[e-mail]]
> > Sent: Friday, December 11, 2015 10:05 AM
> > To: [e-mail]; [e-mail]; draft-ietf-jose-jws-signing-input-
> > [e-mail]
> > 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.
> >
> > 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.
>
> 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.
>
> > 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.
>
> 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
>
>