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: jose@xxxxxxxx
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:ietf-bounces@xxxxxxxx] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
To: draft-ietf-jose-json-web-signature.all@xxxxxxxxxxxxxx
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 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: jose-reg-review@xxxxxxxx. 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 oauth-ext-review@xxxxxxxx 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
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 <Michael.Jones@xxxxxxxxxxxxx> wrote:
Best regards,
Kathleen