Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)
Richard Barnes <rlb@ipv.sx> Tue, 04 November 2014 03:01 UTC
Return-Path: <rlb@ipv.sx>
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 C62BC1A6EEC for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 8nilkGIfV_1q for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:01:48 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2089B1A1BCA for <jose@ietf.org>; Mon, 3 Nov 2014 19:01:48 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id la4so3764293vcb.23 for <jose@ietf.org>; Mon, 03 Nov 2014 19:01:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4U2SgKBxBcwHE6zPeFzLkpTbwdK3GDyqEW3hjNkqjow=; b=DUVtk0YOoEpvUBk8y1Xx2vTQpKG7B7iJcNw8fWBEne6ef0zc1qHIcdNgUKAg44cdmK 5pF17P/IGOzvXq5lV/nBZ8CWkf4Jq26SMcCNWUuT34luxwJq4eMVizeKF4RgZu4bk6++ ozSo1vQEXIRU0eJrZHPMYOP0DgUMfWfl1jF+q5qYs+ICJLi4aalBNp7UVb07vme0ICvj TzwuhV4Ct4F/YdSSbttMqacVYisyNdHg6hq94Ls7CXAq89L5F5/cHi5qZdB0uOVjN+5P af9UGMeFVrwvedUwk8whZhKc+2JTbGIChKOhsNAuZ7n+6XyPE7sVVGIOIkNO8KrIBVb/ ZTDg==
X-Gm-Message-State: ALoCoQleFhnirLZ849Yf2PPfdKYIQxS9uIxvpUiGW6SW7D/LCQKLReTZD3hldaMTFLh6Vf1rWxAQ
MIME-Version: 1.0
X-Received: by 10.220.111.6 with SMTP id q6mr42080046vcp.12.1415070107309; Mon, 03 Nov 2014 19:01:47 -0800 (PST)
Received: by 10.31.149.205 with HTTP; Mon, 3 Nov 2014 19:01:47 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB262B7@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB262B7@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Mon, 03 Nov 2014 22:01:47 -0500
Message-ID: <CAL02cgQsms_t_hjHAyaBv-iw_vBp0792KWWC3P-653BLVj+qMA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="047d7b3a8792143ffa0506ffaf40"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/rYPXiu8j6ZyrqFKU_DfVF8g9nJE
Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)
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: Tue, 04 Nov 2014 03:01:53 -0000
Thanks, Mike. I cleared. On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <Michael.Jones@microsoft.com> wrote: > The simplified single-recipient JSON Serialization syntax has been added > to draft -36. Hopefully this will enable you to clear your remaining > DISCUSS on this draft. > > > > Thanks again, > > -- Mike > > > > *From:* Richard Barnes [mailto:rlb@ipv.sx <rlb@ipv.sx>] > *Sent:* Monday, October 20, 2014 9:21 AM > *To:* Mike Jones > *Cc:* The IESG; draft-ietf-jose-json-web-encryption@tools.ietf.org; > jose-chairs@tools.ietf.org; jose@ietf.org > *Subject:* Re: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT) > > > > > > > > On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > Thanks for your review, Richard. Responses are inline below... > > > > -----Original Message----- > > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 01, 2014 8:37 PM > > To: The IESG > > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose- > > chairs@tools.ietf.org; jose@ietf.org > > Subject: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-encryption- > > 33: (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-jose-json-web-encryption-33: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Overall, this document is in much more solid shape than when it began. > > Thanks to the WG for a lot of hard work. I only have one remaining > concern, > > that should hopefully be easy to address. > > > > Section 7.2. > > I've had several implementors trying to use JWE in the JSON > serialization ask > > why it was necessary to include a "recipients" array in cases where > there's only > > one recipient. It seems like this is going to be a major barrier to > deployment and > > re-use, so I would propose including the following text: > > """ > > In cases where the JWE is encrypted for only one recipient, the > "recipients" array > > will contain a single object. In such cases, the elements of the > "recipients" array > > MAY be included at the top level of the JWE object. If the generator of > a JWE > > chooses to use this representation then all unprotected header parameters > > MUST be carried in the "header" field, and the "unprotected" field MUST > be > > absent. A JSON-formatted JWE that contains a "recipients" field MUST NOT > > contain a "header" or "encrypted_key" field, and vice versa. > > """ > > This may also require some other changes where "recipients" is relied > on, e.g., in > > Section 9. > > My response to this parallels that to the similar DISCUSS about JWS. > > That said, I actually have marginally *more* concerns about this proposal > than the JWS one, because you're making an arbitrary choice between the > multi-recipient "unprotected" parameter and the per-recipient "header" > parameter, and dictating that one be used in preference to another in the > proposed case where "recipients" array is not present. This adds an > additional level of non-parallelism that isn't present in the JWS case. > > For those following along, here are the two mostly equivalent syntaxes > that implementations would have to support in Richard's proposal: > > {"protected":"<integrity-protected shared header contents>", > "unprotected":<non-integrity-protected shared header contents>, > "recipients":[ > {"header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>"}], > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > and > > {"protected":"<integrity-protected shared header contents>", > "header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>", > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > Plus, there would be a third syntax if use of the "unprotected" parameter > were not arbitrarily ruled out, as his proposal does: > > {"protected":"<integrity-protected shared header contents>", > "unprotected":<non-integrity-protected shared header contents>, > "header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>", > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > During the Denver interim meeting in April 2013 and subsequent working > group decisions we all agreed to a specific syntax for the JWE JSON > Serialization. We explicitly agreed to have a "recipients" array, since > this serialization enables multiple recipients. This syntax was > incorporated in draft -11 in May 2013 and has been stable since then. > Given you were an inventor of this syntax, Richard, I'm surprised to see > you questioning it now, this late in the process. > > I'll therefore ask you to withdraw this DISCUSS, since having multiple > syntaxes to represent the same semantics can only hurt interoperability. > > > > FWIW, I'm not necessarily proposing multiple syntaxes. I would be A-OK > with requiring that single-recipient JWEs follow the simplified syntax. > > My comments on the JWS thread about the multiple-recipient case reducing > to the single-recipient case also apply here. An implementor is going to > have to build a single-recipient version *anyway*, since that's how the > crypto works, so we might as well make the syntax match. > > --Richard > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3.3. > > Why doesn't this example include the JSON encoding? > > Same answer as to your parallel question on JWS. > > > Section 4.1.3. > > "This Header Parameter MUST be integrity protected" > > Why is this the case? There is no security reason that "zip" must be > integrity- > > protected, and this requirement isn't made for any other parameter. > > ekr and others stated reasons for this when the compromise about allowing > some non-integrity-protected parameters was reached. I believe that they > boiled down to ensuring that an attacker couldn't vary the contents of the > plaintext by changing the "zip" parameter value as part of an attack. > Given the effectiveness of the CRIME attack against compression in SPDY > since then, this advice seems all the more sound in retrospect. > > > Section 7.2. > > The requirement that the "recipients" field MUST be present seems odd. > > What's the justification for this? > > Simplicity. The structure of a JWE using the JSON Serialization is always > the same that way, simplifying generators and parsers. If this weren't the > case, they'd have to have a special case for the situation where the > "recipients" array was omitted. > > > Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook. > > Developers have found the examples to be useful in practice. Having more > in the cookbook just adds value, without detracting from the value of the > examples in the JWE spec. > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > Thanks again, > -- Mike > > >
- [jose] Richard Barnes' Discuss on draft-ietf-jose… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… ⌘ Matt Miller
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Martin Thomson
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Kathleen Moriarty
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes