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

[Kathleen Moriarty <[e-mail]>]

Thanks, Mike.  Let me know when this is all ready.

Best regards,
Kathleen

On Tue, Dec 22, 2015 at 9:34 AM, Mike Jones <[e-mail]> wrote:
> It’s clear that most people prefer the 100% safe option over the current
> text that relies upon application semantics in some cases.  Thanks, James,
> for suggesting this and thanks to all of you who took the time to look at
> the issue.
>
>
>
> I’ll prepare a new draft reflecting this outcome.  Vladimir, could I ask you
> to once again verify the examples, once they’ve been updated?
>
>
>
>                                                           Thanks all,
>
>                                                           -- Mike
>
>
>
> From: Preibisch, Sascha H [mailto:[e-mail]]
> Sent: Monday, December 21, 2015 9:54 AM
> To: Roland Hedberg <[e-mail]>; Nat Sakimura
> <[e-mail]>
> Cc: [e-mail]; Axel Nennker <[e-mail]>; Jim Schaad
> <[e-mail]>; Mike Jones <[e-mail]>; Kathleen
> Moriarty <[e-mail]>;
> [e-mail]; [e-mail]; Matthew
> Miller <[e-mail]>; John Bradley <[e-mail]>; The IESG
> <[e-mail]>; Stephen Farrell <[e-mail]>
>
>
> Subject: Re: [jose] Stephen Farrell's Discuss on
> draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)
>
>
>
> +1
>
>
>
> From: jose <[e-mail]> on behalf of Roland Hedberg
> <[e-mail]>
> Date: Monday, December 21, 2015 at 8:46 AM
> To: Nat Sakimura <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Axel Nennker
> <[e-mail]>, Jim Schaad <[e-mail]>, Mike Jones
> <[e-mail]>, Kathleen Moriarty
> <[e-mail]>,
> "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, Matthew Miller <[e-mail]>, John Bradley
> <[e-mail]>, The IESG <[e-mail]>, Stephen Farrell
> <[e-mail]>
> Subject: Re: [jose] Stephen Farrell's Discuss on
> draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)
>
>
>
> +1
>
>
>
> 21 dec. 2015 kl. 15:55 skrev Nat Sakimura <[e-mail]>:
>
>
>
> I also think it is better to make the b64 parameter critical. Being
> deterministic makes the life of programmers simpler. It also decreases the
> vulnerability surface. So +1 to James's text.
>
>
>
> 2015-12-21 22:26 GMT+09:00 <[e-mail]>:
>
> I think that the larger a payload is the higher is the risk of a bad verify
> and that few extra bytes don't matter then.
> And I follow Vladimir's argument to try to keep the security concideration
> section simpler.
>
> So +1 to James proposed text.
>
>
> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Matt Miller
> (mamille2)
> Sent: Donnerstag, 17. Dezember 2015 18:19
> To: Kathleen Moriarty; [e-mail]
> Cc: [e-mail]; [e-mail]; Michael Jones; The IESG;
> John Bradley; Stephen Farrell;
> [e-mail]
> Subject: Re: [jose] Stephen Farrell's Discuss on
> draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)
>
> 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
>> <[e-mail]> wrote:
>>
>> On Thu, Dec 17, 2015 at 9:32 AM, John Bradley <[e-mail]> 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 <[e-mail]> 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
>>>>> <[e-mail]> 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:[e-mail]]
>>>>>>> Sent: Thursday, December 17, 2015 2:32 PM
>>>>>>> To: Mike Jones <[e-mail]>; The IESG
>>>>>>> <[e-mail]>
>>>>>>> Cc: [e-mail]; [e-mail];
>>>>>>> draft-ietf-jose-jws-signing- [e-mail];
>>>>>>> [e-mail]
>>>>>>> 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:[e-mail]] Sent: Thursday, December 17,
>>>>>>>>> 2015 12:20 PM To: The IESG <[e-mail]> Cc:
>>>>>>>>> [e-mail]; Mike Jones
>>>>>>>>> <[e-mail]>; Jim Schaad
>>>>>>>>> <[e-mail]>; [e-mail];
>>>>>>>>> [e-mail]; [e-mail] 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-in
>>>>>>>>> put-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-inp
>
>>>>>>>> ut-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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>



-- 

Best regards,
Kathleen