Subject: Re: [Gen-art] Gen-ART review of draft-ietf-jose-json-web-signature-31

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 23:03:29 +0000

Thanks again for your review, Russ.  The proposed resolutions below have been applied in the -32 draft.

                                                                -- Mike

From: Mike Jones
Sent: Monday, August 25, 2014 6:22 PM
To: 'Russ Housley'
Cc: [email-masked]
Subject: RE: 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.

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
To: [email-masked]<mailto:[email-masked]>
Cc: IETF Gen-ART; IETF
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31

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.

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

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

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

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

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.

- 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

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.

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.

I will plan to add the pointer to Section 10.4.

- In Section 4.1.4, should the value match the subject key identifier

  if an X.509 certificate is used?

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.

- In Section 4.1.5, why is TLS required to fetch digitally signed

  X.509 certificates?

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.

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

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:

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

OK

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

OK

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

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.

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

OK

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

OK

- The IANA Considerations section requires the establishment of a new

  mail list: [email-masked]<mailto:[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.

This text was taken from RFC 6749 and the list is modelled after the [email-masked]<mailto:[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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 25 Sep 2014 09:12:18 -0400

Hi Mike,

I'm just going through the updates to reflect the changes in the draft from
the IETF last call and the drafts look pretty good.  I do think an
informative reference to the developing set of best practices for TLS
should be included in Section 8 on requirements for TLS.  Here is the link
and it can get added after the IESG reviews:

https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-03

Thanks.

On Tue, Sep 23, 2014 at 7:03 PM, Mike Jones <[email-masked]>
wrote:

> *From:* Mike Jones
> *Sent:* Monday, August 25, 2014 6:22 PM
> *To:* 'Russ Housley'
> *Cc:* [email-masked]
> *Subject:* RE: 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
> To: [email-masked]
> Cc: IETF Gen-ART; IETF
> 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>.
>
>
>
> 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?)
>
>
>
> 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.)
>
>
>
> 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.
>
>
>
> Minor Concerns:
>
>
>
> 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:
>
>
>
> 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.
>
>
>
>   mail list: [email-masked].  The process for setting up the
>
> 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
>
>
>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Sep 2014 15:29:00 +0000

Sounds good

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 6:12 AM
To: Mike Jones
Cc: Russ Housley; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-jose-json-web-signature-31

Hi Mike,

I'm just going through the updates to reflect the changes in the draft from the IETF last call and the drafts look pretty good.  I do think an informative reference to the developing set of best practices for TLS should be included in Section 8 on requirements for TLS.  Here is the link and it can get added after the IESG reviews:

Thanks.

On Tue, Sep 23, 2014 at 7:03 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks again for your review, Russ.  The proposed resolutions below have been applied in the -32 draft.

                                                                -- Mike

From: Mike Jones
Sent: Monday, August 25, 2014 6:22 PM
To: 'Russ Housley'
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Gen-ART review of draft-ietf-jose-json-web-signature-31

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
To: [email-masked]<mailto:[email-masked]>
Cc: IETF Gen-ART; IETF
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31

Reviewer: Russ Housley

Review Date: 2014-08-24

Major Concerns:

  in Section 2.

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

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

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.

  need to be discussed:

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.

Minor Concerns:

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.

  X.509 certificates?

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:

  OLD:

   JOSE Header

  NEW:

   JOSE Header

OK

      BASE64URL(JWS Signature)

OK

      BASE64URL(JWS Signature)

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.

OK

OK

This text was taken from RFC 6749 and the list is modelled after the [email-masked]<mailto:[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

--

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Fri, 26 Sep 2014 06:58:15 +0000

Given I was already editing to address Stephen’s missed comments, I added this too.

                                                            -- Mike

Hi Mike,

Thanks.

                                                                -- Mike

From: Mike Jones

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
To: [email-masked]<mailto:[email-masked]>
Cc: IETF Gen-ART; IETF
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31

Reviewer: Russ Housley

Review Date: 2014-08-24

Major Concerns:

  in Section 2.

  need to be discussed:

Minor Concerns:

  X.509 certificates?

Other Comments:

  OLD:

   JOSE Header

  NEW:

   JOSE Header

OK

      BASE64URL(JWS Signature)

OK

      BASE64URL(JWS Signature)

OK

OK

                                                                Thanks again,

                                                                -- Mike

--

Best regards,
Kathleen