Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 25 September 2014 13:12 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005B11A0092; Thu, 25 Sep 2014 06:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J__CgsCMDz7p; Thu, 25 Sep 2014 06:12:26 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8692A1A008C; Thu, 25 Sep 2014 06:12:20 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id gb8so3012969lab.16 for <multiple recipients>; Thu, 25 Sep 2014 06:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BKh6PNZLJSWMgZc1yYJntGJj66CMJs2WISaSTx7rF1k=; b=H5m022eWzeJMV2Tja8p0mIu80TsJEMsL4A7G86v/BwF/ZoSBsvsXIvP2NyN8JfeAi9 j8zek3lboj6L3kfwljmePEZzqXm0v/PnLsvVIRwd8k0s4fUEeIQ8u6PqR7WN0cmDLKct cmRHSiFdqa0eJ6xxC553VT1JLjqAQSc+X3k3TmJLRrTqor6WmNbDLifUDeFt5vWL6+4M VTg/EmsTE/iVXZmU45mdLGsK9NbH2B6oIue6MeZT4lDRTSMApyfo2kK5CmidZsdyK/Ov eHA27mwzN2vWWTYob8T7LrviaAYjN8MZR0AsauU/PIfOpMAJddOXrN+gfFsVn2H0DgEB bXUg==
MIME-Version: 1.0
X-Received: by 10.112.205.39 with SMTP id ld7mr12633274lbc.40.1411650738732; Thu, 25 Sep 2014 06:12:18 -0700 (PDT)
Received: by 10.112.41.233 with HTTP; Thu, 25 Sep 2014 06:12:18 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA6ED86@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <D4999910-8500-4114-9670-08436D64FF28@vigilsec.com> <4E1F6AAD24975D4BA5B16804296739439BA6ED86@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Thu, 25 Sep 2014 09:12:18 -0400
Message-ID: <CAHbuEH4du9ft3qf+Ye12b17ZKZYNQGApu27gmzJWOUsPe1OCCQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11c3c41ad443750503e38c80"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/CZ6dv453oplplXDOQADeUdmqDGw
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, Russ Housley <housley@vigilsec.com>, "ietf@ietf.org" <ietf@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Sep 2014 13:12:30 -0000
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.Jones@microsoft.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@ietf.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@ietf.org <ietf-bounces@ietf.org>] On > Behalf Of Russ Housley > Sent: Sunday, August 24, 2014 12:23 PM > To: draft-ietf-jose-json-web-signature.all@tools.ietf.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@ietf.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@ietf.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
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Mike Jones
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Jim Schaad
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Mike Jones
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Kathleen Moriarty
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Mike Jones
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Kathleen Moriarty
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Mike Jones
- Re: [jose] Gen-ART review of draft-ietf-jose-json… Mike Jones