Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31

From: Russ Housley <[email-masked]>
Date: Sun, 24 Aug 2014 15:23:25 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-jose-json-web-signature-31
Reviewer: Russ Housley
Review Date: 2014-08-24
IETF LC End Date: 2014-09-03
IESG Telechat date: unknown

Summary:  Not quite ready.  Some issues to resolve.

Major Concerns:  

- At first reading, I thought that Sections 2 and 3 were defining the
  same terms.  On the second or third reading, I figured it out.
  I think it would be more clear in Section 3 to state that a JWS is
  constructed from a sequence of the things that are already defined
  in Section 2.
  
- In Section 5.2, it says that in some cases, all must successfully
  validate, but in other cases, only a specific signature, MAC, or
  plaintext value needs to be successfully validated. How does the
  recipient know which case applies?

- In Section 8, why not say that TLS 1.2 or later MUST be supported?

- Section 10 says, "The entire list of security considerations is
  beyond the scope of this document..."  This reads like a red flag to
  me.  While it is not possible to discuss every possible implementation
  consideration that impacts security, the document should cover the
  topics discussed in RFC 3552.  At a minimum, I think the following
  need to be discussed:
    -- the consequences of compromise of the signer's private key
    -- the consequences of compromise of the MAC key
    -- the consequences of poor random numbers, which are needed for
       more than just key entropy with some algorithms like ECDSA
    -- awareness that cryptographic algorithms become weaker with time

Minor Concerns:

- Section 1, 1st paragraph says: "The JWS cryptographic mechanisms
  provide integrity protection for an arbitrary sequence of octets."
  This is true, but this is not the whole story.  A sentence or two
  should be added about when a signature mechanism is appropriate
  and when a MAC mechanism is appropriate.  Alternatively, a pointer
  to Section 10.4 could be included.

- In Section 4.1.4, should the value match the subject key identifier
  if an X.509 certificate is used?

- In Section 4.1.5, why is TLS required to fetch digitally signed
  X.509 certificates?

- Section 10.2 talks about chosen plaintext attacks.  However, there
  are much worse things than chosen plaintext attacks that will result
  if a third party can get a signer to sign a content of its choosing.

Other Comments:

- I suggest a rewording for a part of Section 2:

  OLD:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The members of the JOSE
      Header are Header Parameters.

  NEW:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The JOSE Header is composed
      of a set of Header Parameters.

- I think that Section 3.1 would be more clear by saying:

   In the JWS Compact Serialization, a JWS object is represented as:
   
      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      BASE64URL(JWS Payload)  || "." ||
      BASE64URL(JWS Signature)

- I think that Section 3.1 would be more clear by saying:

   In the JWS JSON Serialization, a JWS object is represented as:
   
      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      JWS Unprotected Header || "." ||
      BASE64URL(JWS Payload) || "." ||
      BASE64URL(JWS Signature)

   Then, the text needs to say that whitespace may appear anywhere.

- Some additional whitespace would make Section 7.2 easier to read.

- The IANA Considerations section requires the establishment of a new
  mail list: [email-masked].  The process for setting up the
  list is described at the bottom of this web page:
  http://www.ietf.org/list/nonwg.html.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Aug 2014 20:06:26 +0300

Thanks for your review, Russ. These reviews are very important for me for managing my work load, but more importantly, they improve the quality of our published RFCs.

I share the concern about the main points that Russ brought up. Michael, John, Nat - any thoughts?

Jari

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Aug 2014 18:29:40 +0000

There's a thread on this review on the JOSE working group list, which you can see at http://www.ietf.org/mail-archive/web/jose/current/maillist.html.  If you have comments on the proposed resolutions, please add your thoughts there.

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Wednesday, August 27, 2014 10:06 AM
To: Russ Housley
Cc: IETF Gen-ART; IETF; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-jose-json-web-signature-31

Jari

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Aug 2014 14:55:18 -0400

I just noticed the responses were not sent to Gen-art, IETF, or
[email-masked].  Forwarded thread
for transparency on review.

On Tue, Aug 26, 2014 at 6:00 PM, Mike Jones <[email-masked]>
wrote:

>  So that there are no surprises, I’m also annotating the proposed
> resolutions below to say which of them will also result in parallel changes
> other drafts.
>
>
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Monday, August 25, 2014 9:13 PM
> *To:* Mike Jones; 'Russ Housley'
> *Cc:* [email-masked]
> *Subject:* RE: [jose] Gen-ART review of
> draft-ietf-jose-json-web-signature-31
>
>
>
>
>
>
>
> *From:* jose [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Mike Jones
> *Sent:* Monday, August 25, 2014 6:22 PM
> *To:* Russ Housley
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Gen-ART review of
> draft-ietf-jose-json-web-signature-31
>
>
>
> Thanks for the useful review, Russ.  Proposed resolutions to your comments
> follow inline.  Please let me know if you agree.  Also, working group
> members, please follow this discussion, as these comments will likely
> result in changes to the current drafts.
>
>
>
> From: ietf [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Russ Housley
> Sent: Sunday, August 24, 2014 12:23 PM
> To: [email-masked]
> Cc: IETF Gen-ART; IETF
> Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31
>
>
>
> Gen-ART, please see the FAQ at <
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
>
>
> I understand that there is some repetition between the Terminology section
> and the JWS Overview section.  I will plan to eliminate this duplication in
> the manner you suggested – by simply using, rather restating the
> definitions of, the terms, and saying that they are defined above.  (Jim
> Schaad – note that this will condense some of the text that you’d requested
> be added to Section 3 to explicitly spell out the parts of a JWS, and will
> result in a parallel change to JWE.  Is that OK with you?)
>
>
>
> Given that I would expect the text to be in section 2, this is not an
> issue for me.
>
>
>
> Note that this proposed resolution will also result in parallel changes to
> the JWE spec.
>
>
>
> The recipient knows what application it is part of, and so knows the
> application decisions described in 5.2, paragraph 2 about whether all or
> some signatures must validate.
>
>
>
> I do agree that the text in step 9 (signature validation) could be read as
> being in conflict with paragraph 2.   I’ll plan to modify this to say that
> the step records whether the signature validated, rather than saying that
> it must validate.  Then I’ll add a step 11 saying to reject the input if no
> signature validated and a step 12 saying to return a result indicating
> which signatures were successfully validated, so that the application can
> determine whether to accept the input and which signatures to trust.  Will
> that work for you?
>
>
>
> It’s more complicated a description, but a more general description of the
> things that can happen in the multiple signatures case, in which some
> signatures validate and some don’t and you may need to tell the application
> which ones were good and which were bad.  (It’s much simpler in the single
> signature case, in which you can make a simple accept/reject decision.)
>
>
>
> Note that this proposed resolution will also result in parallel changes to
> the JWE spec.
>
>
>
> This text is modelled after http://tools.ietf.org/html/rfc6749#section-1.6,
> but updated to remove the reference to TLS 1.0.  I don’t believe the
> working group felt that it had sufficient data on TLS 1.2 deployment to
> understand whether it could now safely mandate 1.2 or whether this would
> effectively mean that many deployments would be non-conformant.  Is there
> data saying that greater than N% of devices in common use now support TLS
> 1.2 – where N% is preferably over 90%?  It would be good have such data
> about commonly used platforms such OS X, iOS, Android, Linux, and Windows
> to help inform this decision.
>
>
>
> I agree that the phrase “The entire list of security considerations is
> beyond the scope of this document...” adds no or negative value.  I’ll
> remove it.
>
>
>
> I’ll also plan to explicitly make sure that we address the topics in your
> list above and go through RFC 3552 looking for others that we need to cover.
>
>
>
> Note that this proposed resolution will also result in parallel changes to
> the JWE, JWK, JWA, and JWT specs.
>
>
>
> Minor Concerns:
>
>
>
> I will plan to add the pointer to Section 10.4.
>
>
>
> That was not an intended usage of this field, although nothing precludes
> particular applications from specifying its use in that manner.  Its
> intended usage is to match JWK “kid” values, as described.  I don’t plan to
> make a change to the document in response to this comment unless you
> believe that one is truly necessary.
>
>
>
> This question was explicitly discussed by the working group at IETF 87.
> The discussion is recorded in the minutes
> <http://www.ietf.org/proceedings/87/minutes/minutes-87-jose> as follows:
>
> If there is an x5u pointing to a certification issued by a major CA, is
> TLS required for the HTTP query used to retrieve this certificate?  TLS
> shouldn't be needed since the certificate is a signed object.  Therefore,
> the "MUST" use TLS for cert retrieval should be changed to "SHOULD".  This
> is an application decision.  Mike Jones doesn't want removal of TLS in the
> case where there's no external means to verify the retrieved key.  Matt
> Miller: agrees with the jku case, but argues that for x5u, there is a class
> of applications where it isn't known if the retrieved object is
> self-protecting (like a certificate) until after it is retrieved.  Even if
> the object appears to be self-protecting, if the retriever doesn't have a
> trusted root for that object, it might not be able to verify the protection
> anyhow.  So it use of TLS might still be preferable instead of having to
> potentially retrieve an object twice, once over HTTP and then over HTTPS.
> Joe Hildebrand wanted to know what the upside of this proposal is.  Richard
> says it saves on TLS handshakes; Hildebrand envisions a world where TLS is
> ubiquitous.  Paul Hoffman said that a similar issue in DANE ended up being
> dropped after a couple of months of discussion.  Richard agreed to drop the
> TLS MUST to SHOULD proposal.
>
>
>
> What’s there now is about attackers getting to choose part of the
> plaintext.  I think you’re talking about attacks in which the attacker gets
> to choose the whole plaintext, which is clearly far worse.  At that point,
> the signature of the signer obviously becomes pretty worthless.  Is that
> your point here?  If so, I could take a stab at writing something about
> this, or you could suggest some text if you’d like.
>
>
>
> Other Comments:
>
>
>
> OK
> OK
> Note that this proposed resolution will also result in parallel changes to
> the JWE spec.
>
>
>
> This isn’t accurate.  Assuming you’re talking about 3.2, the
> representation isn’t the concatenation above – it’s a JSON object
> containing some or all of the values above.  Nonetheless, I can try to
> revise the text to be more direct here as well.
>
>
>
> Note that this proposed resolution will also result in parallel changes to
> the JWE spec.
>
>
>
> OK
> Note that this proposed resolution will also result in parallel changes to
> the JWE spec.
>
>
>
> OK
> This text was taken from RFC 6749 and the list is modelled after the
> [email-masked] list described therein.  It’s not clear to me
> whether you want a change to the draft (if so please specify) or whether
> you were just being helpful (which is appreciated).
>
>
>
>                                                                 Thanks
> again,
>
>                                                                 -- Mike
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

-- 

Best regards,
Kathleen