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
>
>
>