Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 27 August 2014 18:55 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 B5B851A00FC; Wed, 27 Aug 2014 11:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.001
X-Spam-Level: ***
X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 8sJuMxR4kK0L; Wed, 27 Aug 2014 11:55:21 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE0A1A00DB; Wed, 27 Aug 2014 11:55:20 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id gl10so440076lab.33 for <multiple recipients>; Wed, 27 Aug 2014 11:55: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=jqLwEVIOHjqKx846PFEa0n7x6P+cjnbNipHif/Gutck=; b=AikKxZsJvCdHu9uqKYEzyQ46qvVP4vMVl6azUtSh2vcyvwTOwktRfQjPuBkYpCMYRd WeNbf9iOvXDsLwgeazVo5DxOdL7GwxSG8zalrwJkx8vFmFZYnu/R8PaUjOtatNGJ7ZtA jDd4NodYCE7PFdW6Lk3tr8KbWFDJ5mDfCUEMifBWdjLR2aUvxeXG9KDcr56gcgGsnOqQ xlh7HCGNLoKQEldh6Pp3zzguZ2PSNNe35zMnrRZKeWBSs40RgKsswlm0hY6363mp840+ /Bemgq8nOGuhACBKQovi3jSUqv9gbJReo5uNqIKQm3fcdTp6pxIQp1wkGIXl61rpQkmf CpmQ==
MIME-Version: 1.0
X-Received: by 10.112.173.136 with SMTP id bk8mr5123836lbc.88.1409165718730; Wed, 27 Aug 2014 11:55:18 -0700 (PDT)
Received: by 10.112.64.170 with HTTP; Wed, 27 Aug 2014 11:55:18 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE44472@TK5EX14MBXC293.redmond.corp.microsoft.com>
References: <D4999910-8500-4114-9670-08436D64FF28@vigilsec.com> <4E1F6AAD24975D4BA5B16804296739439AE40DC4@TK5EX14MBXC293.redmond.corp.microsoft.com> <035801cfc0e4$002fe8d0$008fba70$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439AE44472@TK5EX14MBXC293.redmond.corp.microsoft.com>
Date: Wed, 27 Aug 2014 14:55:18 -0400
Message-ID: <CAHbuEH4m6wV_=LWqM_ix4vwytpsk=qRbzmB9veDE5VZXGo52xQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>, draft-ietf-jose-json-web-signature.all@tools.ietf.org, IETF <ietf@ietf.org>, gen-art@ietf.org
Content-Type: multipart/alternative; boundary="001a11c221ae183d730501a0f6c4"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/bk6VRm443vMwXHtPOTdoI0MlVMA
Cc: Jim Schaad <ietf@augustcellars.com>, Russ Housley <housley@vigilsec.com>, "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: Wed, 27 Aug 2014 18:55:25 -0000
I just noticed the responses were not sent to Gen-art, IETF, or draft-ietf-jose-json-web-signature.all@tools.ietf.org. Forwarded thread for transparency on review. On Tue, Aug 26, 2014 at 6:00 PM, Mike Jones <Michael.Jones@microsoft.com> 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:ietf@augustcellars.com] > *Sent:* Monday, August 25, 2014 9:13 PM > *To:* Mike Jones; 'Russ Housley' > *Cc:* jose@ietf.org > *Subject:* RE: [jose] Gen-ART review of > draft-ietf-jose-json-web-signature-31 > > > > > > > > *From:* jose [mailto:jose-bounces@ietf.org <jose-bounces@ietf.org>] *On > Behalf Of *Mike Jones > *Sent:* Monday, August 25, 2014 6:22 PM > *To:* Russ Housley > *Cc:* jose@ietf.org > *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. > > > > -----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?) > > > > 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. > > > > - 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.) > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - 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. > > > > Note that this proposed resolution will also result in parallel changes to > the JWE, JWK, JWA, and JWT specs. > > > > 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 > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - 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. > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > Then, the text needs to say that whitespace may appear anywhere. > > > > OK > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - 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 > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > -- 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