Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

Justin Richer <jricher@mit.edu> Thu, 17 December 2015 17:42 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF0B1B3006; Thu, 17 Dec 2015 09:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ryJxvbRTn7el; Thu, 17 Dec 2015 09:42:41 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3C1B3004; Thu, 17 Dec 2015 09:42:40 -0800 (PST)
X-AuditID: 12074422-f79c46d000006aa7-7f-5672f40e4c3a
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.43.27303.E04F2765; Thu, 17 Dec 2015 12:42:38 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBHHga3s018817; Thu, 17 Dec 2015 12:42:37 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBHHgX0K015271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Dec 2015 12:42:34 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_2F53BFD6-CAB0-4627-9A8B-13CDCB776E0D"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <45F8D078-A72B-4F6D-87EB-880EF867F4F2@cisco.com>
Date: Thu, 17 Dec 2015 12:42:32 -0500
Message-Id: <EBF4486C-6EAE-49DA-AAF2-2C774C9696C4@mit.edu>
References: <20151217112025.22801.65457.idtracker@ietfa.amsl.com> <BY2PR03MB4429A8A55EB13BCF8227BEBF5E00@BY2PR03MB442.namprd03.prod.outlook.com> <5672B939.4020507@cs.tcd.ie> <BY2PR03MB442F5A1BDF03E7997843CF0F5E00@BY2PR03MB442.namprd03.prod.outlook.com> <5672BD41.3000804@cs.tcd.ie> <2A23B5AE-6E82-4A44-A0D8-3D7970C57438@ve7jtb.com> <B8649513-3B05-417F-B551-46FFDA5689C2@ve7jtb.com> <CAHbuEH4yrcqmJ0uWvv2iZXZjdKGSOzcAH34i6uU2QpSyuUq=ug@mail.gmail.com> <45F8D078-A72B-4F6D-87EB-880EF867F4F2@cisco.com>
To: Matt Miller <mamille2@cisco.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0gUURjFuTOzs+PiyLQ9vK5JNBSRtWahMFauPZQWtqC/Nigop/bmbu3D ZlZxLUxDMZLUwMcqCpaVpPbYJEtCra0IemFo4gMtlSTWNF9QUhvNNFn9d/h+55z7Xe6lcG0e qaNsTjcSnLydJTWENmT5Bn3YvGCObXgawTWeb8Q5749LONdU+ZXkvNPlgGtuLsK43DYXNzcy qOLaK2YJrrK9V801DQXJHRqjr6aSNJZ996mMN4vekca26iG18erVBcxY8CCoNg4O+oj96oOa 7RZkt2UiYZMhVWMNlN1Tp3eYs8o/9pG5IM94AYRQkImDhf5rmKJXwK7h2+QFoKG0TD0Gpwpq cRloGR+ADS1nFDCCwZ4PF6UERS1lPLD/XLLsoZkYGBjoVskenCkD8EfjjEr2QEYHvZ2M7CGZ tbCyOf/3YSFMIuy+8Uola0KaP6sqwpRsAIe3O84BpXQr7C1tUitLzOFw+pFN1suYNfDbwyCh bB0FH34fxUrBkur/9qj+fw8Z4MwGeP3yBK7o9bCzqIFQ9Cp4f7LmzzwB1lf1/ZknwoHiOkzR BjhacUVVB6hGEGVxZOsdvM0uomN68RjvdCJBHx/jsLljkCXjLpBfV53MPgALj1k/YCjAhtJM xymzVsVnih6HH0RQGLuc9kwKZm3YUZfFY+VF6xEhw45EP1gjnTV6p6kL6Ainy4nYZXTShOSj LbwnGwmuRVskRbDhdO38PrOWSePd6CRC6UhYpCspioX06TkpuERAaSjruM3u/ocxKsQPIBUq lefIHlpM5x2iLU3hL8BqXTitlgEjA2uG829W/rmpk0/iAyBcutZSOmdWcoVK//pvOiAVY1Lx G79LLnbz/5AuFxQszJsOd5oOftZX7dvS8Ol6/U/P8xbh9RH6wMxub9KsU1VY2tY7nr8tOiuu JB8ZCp5rNp6YMbwwHMp437/nWSQcvj9b4pkynS3evutta8r4QMrNvbcSTP3JkzmvUOzrQM8V 39RL052xYIAuH2hZtzN2rDv0Vqs3dWt7Xmp/EHq/sIRo5TdH44LI/wJCViC2lAMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/nTVW0qLm6lG5TxOy8fISMb4XPrk>
X-Mailman-Approved-At: Thu, 17 Dec 2015 11:08:01 -0800
Cc: "jose-chairs@ietf.org" <jose-chairs@ietf.org>, Jim Schaad <ietf@augustcellars.com>, Mike Jones <Michael.Jones@microsoft.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "draft-ietf-jose-jws-signing-input-options@ietf.org" <draft-ietf-jose-jws-signing-input-options@ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 17:42:44 -0000

I prefer Jame’s proposal as well.

 — Justin

> On Dec 17, 2015, at 12:19 PM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:
> 
> I prefer James' proposed text.  I believe this draft came about primarily because there are use cases where the content to sign is large enough that the burden of base64url encoding is too great.  By that measure, I'm not sure how worthwhile size-of-header arguments are, as content so large that base64url might be prohibitive would dwarf the concerns around header size.  I think the risk of bad verifies outweighs the reduced-headher-size benefits.
> 
> 
> --
> - m&m
> 
> Matt Miller
> Cisco Systems, Inc.
> 
>> On Dec 17, 2015, at 08:39, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>> 
>> On Thu, Dec 17, 2015 at 9:32 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> Sorry I just recounted, it is a extra 20 bytes per message with the encoded header and not 6.
>>> 
>>> That is a bit more but probably not worth dying over.   I still prefer the smaller option.
>> 
>> If we could get to a consensus on this and which text is preferred,
>> that would be helpful.
>> 
>> Thanks!
>> Kathleen
>> 
>> 
>>> 
>>> John B.
>>> 
>>>> On Dec 17, 2015, at 3:04 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>> 
>>>> I prefer making crit only required if the producer is not certain that all potential recipients understand/the extension.
>>>> 
>>>> However it would not be the end of the world for me from a size perspective if crit was always required.  Trading 6 octets for saving 1/4 of the body size is not a bad trade off.
>>>> 
>>>> The issue for me is more always requiring something to be sent that is known to not be used.
>>>> 
>>>> So I am on the not forcing crit side but could live with the consensus if it goes the other way.
>>>> 
>>>> John B.
>>>> 
>>>>> On Dec 17, 2015, at 2:48 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>>>> 
>>>>> 
>>>>> Great. For completeness, the alternative proposed by James Manger
>>>>> (which I'd also prefer) was:
>>>>> 
>>>>> The "crit" Header Parameter MUST be included with "b64" in its set
>>>>> of values to ensure the JWS is rejected (instead of being
>>>>> misinterpreted) by implementations that do not understand this
>>>>> specification.
>>>>> 
>>>>> My discuss then is asking if, after all this discussion, the WG
>>>>> prefer the above or that below. I'll take the WG chairs word on what
>>>>> they conclude as the outcome.
>>>>> 
>>>>> S.
>>>>> 
>>>>> On 17/12/15 13:44, Mike Jones wrote:
>>>>>> Sure, I'm obviously fine asking the working group what they think of the new text.  Working group - this new text at https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-08#section-6 is:
>>>>>> 
>>>>>> 6.  Using "crit" with "b64"
>>>>>> 
>>>>>> If a JWS using "b64" with a value of "false" might be processed by
>>>>>> implementations not implementing this extension, then the "crit"
>>>>>> Header Parameter MUST be included with "b64" in its set of values to
>>>>>> cause such implementations to reject the JWS.  Conversely, if used in
>>>>>> environments in which all participants implement this extension, then
>>>>>> "crit" need not be included, since its inclusion would have no
>>>>>> effect, other than increasing the JWS size and processing costs.
>>>>>> 
>>>>>>                          Thanks all,
>>>>>>                          -- Mike
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>>>>>> Sent: Thursday, December 17, 2015 2:32 PM
>>>>>>> To: Mike Jones <Michael.Jones@microsoft.com>om>; The IESG <iesg@ietf.org>
>>>>>>> Cc: ietf@augustcellars.com; jose-chairs@ietf.org; draft-ietf-jose-jws-signing-
>>>>>>> input-options@ietf.org; jose@ietf.org
>>>>>>> Subject: Re: Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
>>>>>>> options-08: (with DISCUSS and COMMENT)
>>>>>>> 
>>>>>>> 
>>>>>>> Hiya,
>>>>>>> 
>>>>>>> On 17/12/15 13:20, Mike Jones wrote:
>>>>>>>> Thanks for your review, Stephen.  Replies inline below...
>>>>>>>> 
>>>>>>>>> -----Original Message----- From: Stephen Farrell
>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December 17,
>>>>>>>>> 2015 12:20 PM To: The IESG <iesg@ietf.org> Cc:
>>>>>>>>> draft-ietf-jose-jws-signing-input-options@ietf.org; Mike Jones
>>>>>>>>> <Michael.Jones@microsoft.com>om>; Jim Schaad <ietf@augustcellars.com>om>;
>>>>>>>>> jose-chairs@ietf.org; ietf@augustcellars.com; jose@ietf.org Subject:
>>>>>>>>> Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
>>>>>>>>> options-08: (with DISCUSS and COMMENT)
>>>>>>>>> 
>>>>>>>>> Stephen Farrell has entered the following ballot position for
>>>>>>>>> draft-ietf-jose-jws-signing-input-options-08: Discuss
>>>>>>>>> 
>>>>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>>>>>> this introductory paragraph, however.)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Please refer to
>>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>>>>>>>> information about IESG DISCUSS and COMMENT positions.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The document, along with other ballot positions, can be found
>>>>>>>>> here:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-op
>>>>>>>>> tions/
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> DISCUSS:
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> The "crit" point raised in the gen-art review and maybe elsewhere is I think
>>>>>>>>> correct but I don't think section 6 of -08 is a good resolution of
>>>>>>>>> this topic. However, I'll clear if this is the WG consensus but it's
>>>>>>>>> hard to know that's the case for text just added yesterday. To
>>>>>>>>> resolve this discuss we just need to see what the WG list says about
>>>>>>>>> the new text.
>>>>>>>> 
>>>>>>>> Jim's shepherd write-up at
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-opt
>>>>>>>> ions/shepherdwriteup/ records the working group's desire to not
>>>>>>>> require the use of "crit"
>>>>>>>> when it isn't needed.  He wrote:
>>>>>>>> 
>>>>>>>> "(6)  The fact that there are two different versions of encoding that
>>>>>>>> produce the same text string for signing is worrisome to me.  The WG
>>>>>>>> had the ability to address this when producing the JWS specification
>>>>>>>> and decided not to do so that time.  In this document, the desire to
>>>>>>>> allow for things to be smaller has lead to the fact that the b64 and
>>>>>>>> crit headers can be omitted as being implicit.  This was the desire of
>>>>>>>> the WG, but I personally feel that it is the wrong decision."
>>>>>>> 
>>>>>>> Fair enough, so the chair/shepherd, gen-art reviewer and seems like a few
>>>>>>> IESG members all find the current position unconvincing as does the one
>>>>>>> implementer who posted to the WG list since the new text was added.
>>>>>>> Wouldn't you agree there's enough there to justify asking the WG once more
>>>>>>> what they think about that 13 byte overhead to prevent interop and maybe
>>>>>>> even security problems?
>>>>>>> 
>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> COMMENT:
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> - abstract: the description of the update to 7519 is odd. It seems to be saying
>>>>>>>>> "Here we define a thing. This specification updates 7519 to say you
>>>>>>>>> must not use this thing." but prohibiting is an odd verb to use
>>>>>>>>> there. (Since it wasn't previously there to be allowed or not.)
>>>>>>>> 
>>>>>>>> Would you like this text better?
>>>>>>>> 
>>>>>>>> "This specification updates RFC 7519 by stating that JSON Web Tokens
>>>>>>>> (JWTs) MUST NOT use the unencoded payload option defined by this
>>>>>>>> specification."
>>>>>>> 
>>>>>>> Better yep. Thanks.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Or do you think this spec doesn't need to have the "Updates 7519"
>>>>>>>> clause at all?  People seemed split on whether this was needed or not.
>>>>>>> 
>>>>>>> Happens all the time. Personally I mostly don't care about updates which is
>>>>>>> the case this time too:-)
>>>>>>> 
>>>>>>>> 
>>>>>>>>> - section 6: "It is intended that application profiles specify up
>>>>>>>>> front whether" "intended" is very wishy washy and "up front" makes no
>>>>>>>>> sense at all.
>>>>>>>> 
>>>>>>>> How about this wording change? "It is intended that application
>>>>>>>> profiles specify up front whether" -> "Application profiles should
>>>>>>>> specify whether"
>>>>>>> 
>>>>>>> Also better,
>>>>>>> Ta,
>>>>>>> S.
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks again, -- Mike
>>>>>>>> 
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> 
>> Best regards,
>> Kathleen
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose