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

Mike Jones <Michael.Jones@microsoft.com> Mon, 14 December 2015 03:50 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825171A6F59; Sun, 13 Dec 2015 19:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OByBVkQKgCmL; Sun, 13 Dec 2015 19:50:39 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3A61A6F3C; Sun, 13 Dec 2015 19:50:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zBh/mHgymtYFqFQfNH4EoQ6bk5332rE+yVEOxkx8Y88=; b=f3Tys5bLngPLCiVm56rFQRiY5Bv0GfGMKacI+DEIOl5qaGMPE0GJ8j22qQyz8g38JFZL2jonnismH1Oe+HpYzi8/wLgf8os1vUPJijF3IKm0rWU0TYbAXh3GU5tQmWBKrs06nsc58lwHlojpO6UBnW+L/73S9wlzKEWtbKsUNMM=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 03:50:21 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 03:50:21 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: secdir review of draft-ietf-jose-jws-signing-input-options-06
Thread-Index: AQHRND5yABvUUZjq8E6qK5eNiUXF1Z7ILfEwgAAWPYCAAACDMIABi4UAgAAIwQCAAAHY0A==
Date: Mon, 14 Dec 2015 03:50:20 +0000
Message-ID: <BY2PR03MB442869845352C5E62CD33F4F5ED0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <alpine.GSO.1.10.1512111248420.26829@multics.mit.edu> <BY2PR03MB442A7FF30189B4A39215B74F5EC0@BY2PR03MB442.namprd03.prod.outlook.com> <8C206A9F-8629-4D6C-9EEA-25B71BF586D9@gmail.com> <BY2PR03MB442EC5B63F046735CF13227F5EC0@BY2PR03MB442.namprd03.prod.outlook.com> <CAHbuEH6ONNAjmjZ+KvkEnCf28=sqveFc3Rkg4DEVmXqasnmneA@mail.gmail.com> <CAHbuEH4KTL7EKAsPt7fmmD7D0cRdBT_0Pg3t+uVXgGdzm_tGKg@mail.gmail.com>
In-Reply-To: <CAHbuEH4KTL7EKAsPt7fmmD7D0cRdBT_0Pg3t+uVXgGdzm_tGKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [188.92.133.18]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:ItdbCxpb5tW1f9LYwk11JbpDcJPQXstJblVK6puwyoPr5dFZQtDxFy81zo80HT/B8stUnOpAdJ9YNx2CwBPQuWEABoCPwRqV84QWbUi/o+PCxk8127rqKu64+rW1IPJ/kdCUQYg7kYmbBueT7SINWg==; 24:+ykrU055YZ5Nf98BDmaNktCYOe9UUhbN5QgeDyfoz7z9SNuJKyoXJInNJ8HpPKx5eJTaNbKIz+IxeHjP0sA0R1LupQi4JzIrhBe39LogRMI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: <BY2PR03MB4431A11E41D78984ECE5CD6F5ED0@BY2PR03MB443.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443;
x-forefront-prvs: 0790FB1F33
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(51914003)(24454002)(13464003)(164054003)(53754006)(158454003)(52604005)(8990500004)(10400500002)(66066001)(10290500002)(1220700001)(99286002)(105586002)(1096002)(106116001)(19580395003)(81156007)(87936001)(110136002)(189998001)(97736004)(5001960100002)(19580405001)(76576001)(106356001)(86612001)(76176999)(54356999)(11100500001)(86362001)(122556002)(50986999)(40100003)(5005710100001)(33656002)(2950100001)(93886004)(92566002)(5003630100001)(5003600100002)(2900100001)(74316001)(5002640100001)(77096005)(230783001)(5004730100002)(3846002)(5008740100001)(586003)(102836003)(101416001)(10090500001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 03:50:20.6007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/2d31MIYxcZs5GYRYmta4Dt7mWyo>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-jose-jws-signing-input-options.all@ietf.org" <draft-ietf-jose-jws-signing-input-options.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2015 03:50:42 -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:kathleen.moriarty.ietf@gmail.com] 
Sent: Sunday, December 13, 2015 7:37 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>du>; iesg@ietf.org; secdir@ietf.org; draft-ietf-jose-jws-signing-input-options.all@ietf.org
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 <kathleen.moriarty.ietf@gmail.com> 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 
> <Michael.Jones@microsoft.com> wrote:
>> Sounds good.  Thanks, Kathleen.
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Saturday, December 12, 2015 7:28 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Benjamin Kaduk <kaduk@MIT.EDU>DU>; iesg@ietf.org; secdir@ietf.org; 
>> draft-ietf-jose-jws-signing-input-options.all@ietf.org
>> 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 <Michael.Jones@microsoft.com> 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: iesg@ietf.org; secdir@ietf.org;
>>>> draft-ietf-jose-jws-signing-input-
>>>> options.all@ietf.org
>>>> 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,
Kathleen