Given I was already editing to address Stephen’s missed comments, I added this
too.
-- Mike
From: Kathleen Moriarty
[mailto:kathleen(_dot_)moriarty(_dot_)ietf(_at_)gmail(_dot_)com]
Sent: Thursday, September 25, 2014 6:12 AM
To: Mike Jones
Cc: Russ Housley; jose(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
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:
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-03
Thanks.
On Tue, Sep 23, 2014 at 7:03 PM, Mike Jones
<Michael(_dot_)Jones(_at_)microsoft(_dot_)com<mailto:Michael(_dot_)Jones(_at_)microsoft(_dot_)com>>
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: jose(_at_)ietf(_dot_)org<mailto:jose(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
To:
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org<mailto:draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
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:
jose-reg-review(_at_)ietf(_dot_)org<mailto:jose-reg-review(_at_)ietf(_dot_)org>.
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(_at_)ietf(_dot_)org<mailto:oauth-ext-review(_at_)ietf(_dot_)org>
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