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