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

[Mike Jones <[e-mail]>]

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:
> ----------------------------------------------------------------------
> 
> Moving this first one from a comment to a discuss in light of Richard's
> comment:
> 
> 3.1/4.1/5.1/6.1: Why are there implementation requirements in this document?
> I am also curious, as Richard is, whether these are going to be used at all, and I'd
> like to hear the explanation that the WG had for including these. Are
> implementation requirements for JOSE different from implementation
> requirements for any other use of signing or encryption for each of these
> algorithms? Don't we already have a separate general registry of algorithms and
> their implementation statuses? Why are these necessary?

There are implementation requirements so that implementations will actually be interoperable in practice and not just in theory.  This was discussed by the working group as issue #10 http://trac.tools.ietf.org/wg/jose/trac/ticket/10 and the chairs made a call to keep the implementation requirements, based upon IESG feedback that MTI features are required to enabling interoperability during chartering discussions, as well as based upon feedback from some working group members.

> 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?

> 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.

> 4.8.1.1: Same as 4.6.2.

Same answer.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> For the life of me, I can't figure out why this document set uses the terminology
> "JSON Web Foo". Seems like buzzword nonsense. I would have much preferred
> "JOSE Foo" for each one.

The etymology of the term "JSON Web Token" is that the "JSON Web Token" was conceived of as a JSON-based replacement for the "Simple Web Token".  The relationship between JWTs and SWTs is described in Appendix C of the JWT spec.  When the signature encoding description was split out of the JWT spec, the natural name was "JSON Web Signature".  The JWE, JWK, and JWA names soon followed.

> 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.)

> [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.

> 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.

>    In Direct Key Agreement mode, the output of the Concat KDF MUST be a
>    key of the same length as that used by the "enc" algorithm.
> 
> and
> 
>    In Key Agreement with Key Wrapping mode, the output of the Concat KDF
>    MUST be a key of the length needed for the specified key wrapping
>    algorithm.
> 
> s/MUST/will?

MUST.  The caller of Concat passes the desired length as an input parameter.

> 4.6.1.2/4.6.1.3: These are not very well defined, and it's not clear why they need
> to be base64ed. What are they?

These are parameters of the Concat KDF.  Their primary definitions are in Section 5.8.1 of [NIST.800-56A].  They need to be base64url encoded because JSON can't represent arbitrary binary octet sequences.

> 5.2.2.1:
> 
>        Here we denote the number of octets in the MAC_KEY as
>        MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;
> 
> Oh, dear. That's a pretty convoluted way of saying (I think) "MAC_KEY_LEN is
> the number of octets in MAC_KEY and ENC_KEY_LEN is the number of octets in
> ENC_KEY." If you mean something different, you best explain.

Yes, that's what is meant.  I'll try to reword this to use less convoluted language.

>        the values of these parameters are specified by the Authenticated
>        Encryption algorithms in Sections 5.2.3 through 5.2.5.
>        The number of octets in the input key K MUST be the sum of
>        MAC_KEY_LEN and ENC_KEY_LEN.
> 
> "MUST"? Do you mean "is"?

Ironically, in his secdir review, Charlie Kaufman requested that the language be changed from "is" to "MUST be", hence the present wording.  He wrote:

Section 5.2.2.1 says "The number of octets in the input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say something like "MUST BE the sum". The text goes on to say that the two keys must not overlap, but it is also important that an implementation not tolerate a gap between the two keys is a too large key is provided.

>        When generating the secondary keys
>        from K, MAC_KEY and ENC_KEY MUST NOT overlap.
> 
> Isn't that completely redundant? If length of K is the sum of MAC_KEY_LEN and
> ENC_KEY_LEN, then MAC_KEY and ENC_KEY *can't* overlap.

This text was written by David McGrew.  I agree that it's redundant (although correct), but I retained it on the assumption that he put it there for a reason.

> 6.2: s/MUST be/is

OK

				Thanks again,
				-- Mike