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

Kathleen Moriarty <> Mon, 14 December 2015 03:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87D4F1A1B6C; Sun, 13 Dec 2015 19:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SFO9FoDuiTBs; Sun, 13 Dec 2015 19:37:18 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D1CC1A1BB9; Sun, 13 Dec 2015 19:37:18 -0800 (PST)
Received: by with SMTP id p66so26045820wmp.0; Sun, 13 Dec 2015 19:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zxcIUCejwh9vd0ICHtTqs0+C/wOCE+mows5ySEeIa1A=; b=PRbChvo4KsKXpMLuNrXrmSxUU9iHi3eQXkMAKcNhJC8VcvG9E4q2CpUsgSU61hqe+E PMj+AIctTLCHtE2OTOCgedy/aQ7EtlSpIvQwNVk30Cxgrz2MpK+Ylz+ou32taNizhiRP yMdc837+++duZk/U3ojB6rA1qO+WppizvdEk3YA6js9CZWv4y80Kj91Ki4ofCkJL12Ov ktewINdyTAwlU3ocS2QoZuGMYwbu5OCO8C2iInBhIqZSwgDKGXuwdEVRr064eHYn0EiY HB/OVzVKE9kggV8x5u9aYE84tn5wAdpI9yCBXlO9HiL3R/8MVZBdcFdhVJgdzNlWDIFt XD3A==
MIME-Version: 1.0
X-Received: by with SMTP id de7mr34045762wjc.119.1450064236719; Sun, 13 Dec 2015 19:37:16 -0800 (PST)
Received: by with HTTP; Sun, 13 Dec 2015 19:37:16 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sun, 13 Dec 2015 22:37:16 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Mike Jones <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Dec 2015 03:37:20 -0000


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.


On Sun, Dec 13, 2015 at 10:05 PM, Kathleen Moriarty
<> wrote:
> 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
> On Sat, Dec 12, 2015 at 10:30 PM, Mike Jones
> <> wrote:
>> Sounds good.  Thanks, Kathleen.
>>                                 -- Mike
>> -----Original Message-----
>> From: Kathleen Moriarty []
>> Sent: Saturday, December 12, 2015 7:28 PM
>> To: Mike Jones <>
>> Cc: Benjamin Kaduk <kaduk@MIT.EDU>DU>;;;
>> Subject: Re: secdir review of draft-ietf-jose-jws-signing-input-options-06
>> Sent from my iPhone
>>> On Dec 12, 2015, at 9:33 PM, Mike Jones <> wrote:
>>> Hi Ben,
>>> Thanks for the useful review.  Replies are inline below...
>>>> -----Original Message-----
>>>> From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]
>>>> Sent: Friday, December 11, 2015 10:05 AM
>>>> To:;;
>>>> draft-ietf-jose-jws-signing-input-
>>>> 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.
>> 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
>>>> 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
> --
> Best regards,
> Kathleen


Best regards,