Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

[Mike Jones <[e-mail]>]

> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Monday, October 06, 2014 3:36 PM
> To: Mike Jones
> Cc: Stephen Farrell; The IESG; [e-mail]; [e-mail]; draft-
> [e-mail]
> Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-
> algorithms-33: (with DISCUSS and COMMENT)
> 
> The reference for key lengths is SP-800-57
> http://csrc.nist.gov/publications/nistpubs/800-57/sp800-
> 57_part1_rev3_general.pdf

Thanks for this reference, John.  I'll plan to use it where the 2048 bit requirement is specified.

> Note table 2 lists 80 bits of security for RSA k=1025 and ECC f=160-233  and 112
> bits for RSA k=2048 and ECC f=224-255
> 
> Table 4 lists 80 bits as being disallowed for applying while it may still be used for
> legacy use processing.
> 112 bits is acceptable to 2030 (if we are lucky).
> 
> There is no real legacy use of JOSE so starting at 112 bits seemed reasonable.
> (Depending on a number of factors this should be a minimum depending on how
> long you want to have integrity over verifying the signatures.)
> 
> John B.
> 
> 
> 
> 
> On Oct 6, 2014, at 4:54 AM, Mike Jones <[e-mail]>
> wrote:
> 
> > Thanks for your review, Stephen.  I've included the working group on the
> thread so they're aware of your comments.
> >
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[e-mail]]
> >> Sent: Thursday, October 02, 2014 3:37 AM
> >> To: The IESG
> >> Cc: [e-mail]; draft-ietf-jose-json-web-
> >> [e-mail]
> >> Subject: Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33:
> >> (with DISCUSS and COMMENT)
> >>
> >> Stephen Farrell has entered the following ballot position for
> >> draft-ietf-jose-json-web-algorithms-33: 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
> >> http://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:
> >> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> DISCUSS:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> >> Sorry to pile on, but I guess such a detailed and broad piece of work
> >> is likely to attract many comments and discusses.
> >> Mine should be cleared up easily enough I hope.
> >>
> >> (1) 6.3.2.7: Hmm, where was that discussed on the list?  I think it'd
> >> be better if >2 prime RSA was considered a separate algorithm. (I
> >> vaguely recall some IPR with such moduli for some uses too, but not
> >> sure.) I'd recommend dropping the whole "oth" parameter entirely.
> >> (I'll clear this discuss once its clear that this was discussed by
> >> the WG, I just want to check as I don't recall it.)
> >
> > This was discussed in the thread "private keys, leading zeros" initiated by
> James Manger on August 15, 2012.  (Sorry, I can't get you the archive URL
> reference at present because I'm writing this offline on an airplane over the
> Pacific.)  It was also discussed as issue #153.  This feature was directly modelled
> on RFC 3447.  Applications are free to profile the JWK spec to prohibit the use of
> such keys, so I don't see a compelling case to remove it.
> >
> >> (2) Instructions to DEs: would registering DES be considered ok or
> >> not? What about myJustInventedPrivateAlg?  What about a request for
> >> 10 ccTLD specific Algs? I think these need a bit more clarity wrt
> >> cryptographic "goodness." As a nit, "makes sense" isn't going to help
> >> too much, we've seen that reasonable folks can differ on that here.
> >> Again I don't recall that discussion on the list, but please point me at it if it
> happened.
> >
> > Registering DES with the Implementation Requirements value "Prohibited"
> would be permitted.  The instructions on the "JOSE Implementation
> Requirements" registry field include:
> >    Any identifiers registered for non-authenticated encryption algorithms
> >    or other algorithms that are otherwise unsuitable for direct use
> >    as JWS or JWE algorithms must be registered as "Prohibited".
> >
> > Note that this capability was added at the request of the W3C WebCrypto WG.
> (WebCrypto is choosing to support some algorithms that JOSE explicitly chose
> not to, including some non-authenticated encryption algorithms.)  "Deprecated"
> is also a value available to registrants and the DEs.
> >
> > If you want to supply additional proposed language to the DEs, that would be
> welcomed.
> >
> >> ---------------------------------------------------------------------
> >> -
> >> COMMENT:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> >> - Unlike others, I do think implementation requirements are needed.
> >> The WG did specifically discuss this (a lot) and landed where it did.
> >> I don't think the IESG should second guess that without specific evidence that
> it'd cause damage.
> >> (Richard's points were made previously I believe.)
> >
> > I concur with your synopsis of the discussion that occurred in the working
> group and the conclusions reached.
> >
> >> - 3.3 (and elsewhere) says 2048 bits or larger. I guess that
> >> 2049 bit keys might not work for many implementations and are not a
> >> great idea (as Bleichenbacher works quicker against such lengths if I
> >> recall correctly). Could be worth a note somewhere even though I guess most
> folks know what's what.
> >
> > Rather than us inventing new text, is there an RFC or other doc we can
> reference that provides appropriate guidance on acceptable RSA key lengths?  I
> know that the 2048 came from NIST key usage requirements that I believe ekr
> pointed us to.
> >
> >> - 4.1 (and elsewhere): adding table captions with numbers would be good.
> >
> > I don't feel strongly about this, but each table is in its own section, and so can
> be referenced by section number.  I'd experimented with adding captions at one
> point and it just seemed to take up additional vertical space without making the
> spec clearer.  But I could be convinced otherwise.  Why do you want captions?
> >
> >> Col 1 of the final 3 rows are unfortunate.
> >
> > I don't know how to teach xml2rfc to not do what it did to the final 3 rows, but
> I can make a note to have the RFC editor manually address this if the tool can't.
> >
> >> - Surprised there was no need for integer DH. Can be added later I guess.
> >
> > No one has previously asked about it.  But there registry will be there for it to
> be added, if wanted/needed.
> >
> >> - 6.2.1: Given that the point compression IPR is now expired
> >> (right?) did the WG consider now allowing that? I wondered how much
> >> work it would be to add now, vs to add later. If "later" would cause
> >> a lot of duplication, then maybe "now"
> >> would actually be worth it. ("Later" might also be fine considering
> >> the current work in CFRG on additional curves.)
> >
> > I recall that in the discussions, people were happier having a single
> representation than multiple representations.  Given the curve discussions, that's
> also another reason I'd opt for "later".
> >
> >> - 6.3.1.1: allowing the extra 0x00 would be a better choice IMO, but
> whatever.
> >> Those were historically added so that buggy decoders wouldn't wrongly
> >> think numbers negative, which could still happen maybe.
> >
> > Yeah, I realize why the Java library does this.  This was another case where we
> decided that having a single representation would create less interop problems
> down the road than allowing multiple representations.
> >
> >> - 7.1, 2nd para: why not RSA2048 earlier then?
> >
> > I don't actually recall.  I think the two choices reasonably available to us at this
> point are to either keep or delete this paragraph.  Which would you prefer?
> >
> >> - 7.1.1: It might help the DE if the template here required
> >> references to well know academic crypto conference publications that
> >> consider cryptanalysis of the alg in question, e.g. from crypto, or
> >> eurocrypt etc. One good rule of thumb here is that if there are no
> >> such references then you really should not register the thing.
> >
> > Good idea.
> >
> >> - 8.3: Is 65537 considered a "low" e?  "Low" is too vague there.
> >
> > No, it's not "low", but I can't back that up with a reference off the top of my
> head.  Working group, what are the relevant documents here that we could
> reference for this information?
> >
> >> - 8.5: I'd prefer there was no none. The WG did discuss it though, so
> >> I'll hold my nose.
> >
> > Understood.
> >
> >> - 8.6: suggesting a CA as a cure for oversized keys is odd, I think
> >> those are separable things and e.g. TOFU might be just as or more
> >> effective then X.509 here.
> >
> > Sean Turner suggested adding that text on July 6, 2012.  Proposed edits would
> be welcomed.
> >
> >> - Appendix A:  Thanks for that! It'll save folks a lot of time. Might
> >> be better presented as a set of records and not as a fixed width table.
> >
> > You're welcome!
> >
> > I'll plan to work with the RFC Editor to figure out how to best present it and
> how to achieve that.  I agree that the presentation is screwed up right now.
> >
> >> - I think most of the secdir stuff has been handled (and thanks for
> >> that) so I'm fine that the authors and AD are on top of that.
> >
> > Thanks again for your review and your participation in the working group.
> >
> > 				-- Mike
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose