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

Kathleen Moriarty <> Sun, 13 December 2015 03:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09F991A8ADE; Sat, 12 Dec 2015 19:28:34 -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 H8zxjc9wEiv2; Sat, 12 Dec 2015 19:28:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 099111A8AD9; Sat, 12 Dec 2015 19:28:32 -0800 (PST)
Received: by qgfb51 with SMTP id b51so23306922qgf.3; Sat, 12 Dec 2015 19:28:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=azHYJ4NsGAOEk/WQOJ8PM7sHY82jB9hK/NPGJ/Mb5fE=; b=DJ7yBMMwv+diYA2jzKSym73YuZrrCTlLMMjZsgtmg6cj+WF1RWelCj69M4ASm8+MEC ukMBiYREfPpwZ0LTggr4LnKh8kNq6fI9zvQ0OivoNeauJGf8q1SOcj813I9wekdIMhpU 04211p2iZjTYnjD0dfADE/4AP0n2wQwHaLVfKmQtia4iCT5dRkDlAglXgQgQTo9qA3R0 3m0KDbB0PdeaW0tXg89PJqa+aG7imNYrI0QReBZ9nhVZEQYKk5fbLI+P1Hj9MQ8L0CQT EER+2nOmA+a9j+7uB4UEO4HRB3iTqxlxV5udcWse0PqUmMmflC+hg+O60smL8a28DI/Z ly/w==
X-Received: by with SMTP id f197mr25730818qhf.72.1449977311234; Sat, 12 Dec 2015 19:28:31 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 31sm11254485qgy.13.2015. (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Dec 2015 19:28:30 -0800 (PST)
From: Kathleen Moriarty <>
X-Google-Original-From: Kathleen Moriarty <>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <>
Date: Sat, 12 Dec 2015 22:28:29 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mike Jones <>
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: Sun, 13 Dec 2015 03:28:34 -0000

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!

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