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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Saturday, October 04, 2014 6:07 PM
> To: Pete Resnick; The IESG
> Cc: [e-mail]; [e-mail]; draft-ietf-jose-json-web-
> [e-mail]
> Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-
> algorithms-33: (with DISCUSS and COMMENT)
> 
> Thanks for your review, Pete.  I'm adding the working group so they re aware
> of these comments.  At Stephen Farrell's request, I'm responding with "> "
> line prefixes on previous thread content.  I'm also repeating (and in some
> cases, augmenting) my previous responses to the DISCUSS comments in this
> consolidated response.
> 
> > -----Original Message-----
> > From: Pete Resnick [mailto:[e-mail]]
> > Sent: Wednesday, October 01, 2014 8:04 PM
> > To: The IESG
> > Cc: [e-mail]; draft-ietf-jose-json-web-
> > [e-mail]
> > Subject: Pete Resnick's Discuss on
> > draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
> >
> > Pete Resnick 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:
> > ----------------------------------------------------------------------
> 
> > 4.6.2: AlgorithmID. UTF-8 has me worried here. It has me more worried
> > in 4.8, but we'll talk about that later. Here, aren't all "enc" and "alg"
> > values US-ASCII anyway? Saying US-ASCII here would solve the problem,
> > so unless you think you're going to have the M tleyCr e algorithm,
> > perhaps we can avoid any concerns for this case. (My concern is that you
> can have "interesting"
> > UTF-8 strings with ZERO-WIDTH JOINERs and other nonsense that you
> > probably don't mean to address.
> 
> Even if people used pathological Unicode characters, the exact-match string
> comparison rules would handle this OK.  In practice, what I think we should
> do is provide guidance in the IANA registry instructions that only reasonable,
> displayable Unicode character sequences be registered.  I m reluctant to tell
> people using non-US character sets that they can t use printable glyphs from
> their own languages.  Do people have a suggestion what language this
> guidance should contain?

I agree with Mike that we should move away from the ASCII centric world.  I think this falls under the case of really obvious things that designated experts should be checking for.  I am not sure that I believe that any changes are required for this.

> 
> > 4.8:
> >
> >    The PBES2 password input is an
> >    octet sequence; if the password to be used is represented as a text
> >    string rather than an octet sequence, the UTF-8 encoding of the text
> >    string MUST be used as the octet sequence.
> >
> > This one worries me a lot. It's one thing to say that the password is
> > an octet sequence and the application above is responsible for
> > collecting it from the user and passing it in the correct form. But to
> > say down here in the guts that it MUST be UTF-8 brings up all sorts of
> > ugly questions regarding normalization. I don't think you want to
> > touch this with a 10-foot-pole. I certainly thing you want to stay away from
> that MUST.
> 
> To achieve interoperation, some encoding has to be specified, and UTF-8
> seems like the best choice.  Restricting human-visible passwords to ASCII isn t
> reasonable for most cultures.
> 

I think that your issues with this could in some degree be addressed by having a highlighting pointer to section 9, or to just include the section 9 text at this location.  People generally think of password as being strings, which I admit is only partly true, and at least in JavaScript this is going to be more enforced as there is no real way to distinguish between text strings and octet strings.  I was curious and looked at the precis on passwords and note that it assumes that the strings are UNICODE strings and therefore some type of method of going from UNICODE strings to octet sequences.  I would probably be more inclined to agree with you if I did not expect this to be so heavily used in JavaScript.


> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 3.2:
> >
> >    A key of the same size as the hash output (for instance, 256 bits for
> >    "HS256") or larger MUST be used with this algorithm.
> >
> > Is this specific to JOSE, or is this a general requirement for use of
> > SHA-2? If the latter, a reference would be better than a MUST in here.
> 
> This is an additional requirement imposed by the JOSE use of this algorithm.
> (I believe this requirement was proposed by ekr.)

The specificity of this requirement is not a SHA-2 requirement.  The actual reference that would be used would be NIST SP 800-107-rev 1 section 5.3.4.  I am will versed in reading such specifications and how hash algorithms function.  It still took me about 4 readings through this section to figure out what was actually being said.   Having this simple statement in the document seems to be much easier to understand.

The document says - security = min(key length, hash internal barrel size * 2)

> 
> > [There are many things in the document that look like algorithm
> > requirements and not JOSE requirements. I've noted a few more below,
> > but these should be looked for generally. If something is part of the
> > definition of the algorithm and documented elsewhere, no need to have
> > requirements language, let alone a description of how to run the
> > algorithm, in this document; that should be an external reference.]
> 
> Another example is that we require 2048 bit keys or larger for RSA signatures.
> This is informed by the NIST algorithm usage requirements.  Per ekr's input
> during the BoF that led to JOSE, there's no point in allowing the use of
> deprecated algorithms or key sizes in a new cryptographic format.

I could go either way on saying that these types of restrictions and recommendations are in this document or not.  They are not part of CMS so that they need to be specified by any document such as S/MIME that uses CMS.  Having them here means that initially documents such as JWT do not need to specify them.   I think this is part of the mandatory to implement so that an application has a minimum set of algorithms that it knows it can use for all libraries.

> 
> > In the 5th paragraph (the one right after the table), strike
> > everything after the first sentence. Decoding and encoding are things
> > that are JWS specific and should not be in this document.
> 
> In numerous cases, this document is intentionally about how JOSE uses these
> algorithms and not purely about abstract algorithms.  The particular text you
> cite is there to help developers get the validation right, and explains two
> ways that it can be correctly coded.  Another example of where the JWA
> document is intentionally JOSE specific is that the PBES2 algorithms define
> Header Parameter values.
> 
> > 3.3/3.5/4/2/4.3:
> >
> >    A key of size 2048 bits or larger MUST be used with this algorithm.
> >
> > Is this specific to JOSE, or is this a general requirement for use of RSA?
> 
> This is informed by NIST's current guidance on how to use RSA.
> 
> > 3.6: This section seems to be for the JWS document, not this one. If
> > you want to define the "None" algorithm, go ahead and do that, but
> > describing its use in JWS doesn't belong here.
> 
> This section defines the algorithm identifier "none" and its meaning.  An early
> working group decision was that all algorithm identifiers would reside in the
> JWA document and not the JWA, JWE, or JWK specifications.
> 
> > 4.6:
> >
> >    A new ephemeral public key value MUST be generated for each key
> >    agreement operation.
> >
> > Again, specific to JOSE, or requirement of ECDH-ES?
> 
> I believe that this is a JOSE requirement which may be more conservative
> than strictly required, but was included to err on the side of both security and
> simplicity.  Without this simple requirement, developers would be likely to
> use ECDH-ES insecurely.
> 

This is a frequently stated requirement for ES algorithms.  You get some interesting arguments such as the one that raged for a while in the CFRG mailing list that was saying - we can use an ephemeral key for a "short" amount of time.  Explicitly stating this requirement seems to be a good idea.

> 
> 				Thanks again,
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose