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

[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