Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)

Mike Jones <Michael.Jones@microsoft.com> Tue, 14 October 2014 12:55 UTC

Return-Path: <Michael.Jones@microsoft.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 B40F41A87BB; Tue, 14 Oct 2014 05:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 F7HDkvDJg4S2; Tue, 14 Oct 2014 05:55:21 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716F81A87B9; Tue, 14 Oct 2014 05:55:21 -0700 (PDT)
Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by BN3PR0301MB0836.namprd03.prod.outlook.com (25.160.154.146) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 14 Oct 2014 12:54:52 +0000
Received: from BY2FFO11FD050.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:54:52 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD050.mail.protection.outlook.com (10.1.15.187) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:54:52 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:54:21 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, The IESG <iesg@ietf.org>
Thread-Topic: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)
Thread-Index: Ac/nrfJFldzmk4Q7Q+awOlJ1KwWsIA==
Date: Tue, 14 Oct 2014 12:54:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D5EB@TK5EX14MBXC286.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(199003)(377454003)(13464003)(43784003)(52044002)(51704005)(99396003)(15202345003)(6806004)(55846006)(561944003)(33656002)(120916001)(85806002)(85852003)(66066001)(97756001)(19580395003)(76482002)(19580405001)(44976005)(87936001)(2656002)(21056001)(4396001)(86612001)(31966008)(86362001)(97736003)(50986999)(84676001)(54356999)(15975445006)(92566001)(26826002)(92726001)(81156004)(106466001)(69596002)(95666004)(85306004)(104016003)(77096002)(230783001)(23726002)(107046002)(20776003)(46102003)(80022003)(64706001)(68736004)(47776003)(50466002)(46406003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0836; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0836;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03648EFF89
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/W4TTTfiEtMZYc5d5bs6Stm9uqtA
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>, "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, 14 Oct 2014 12:55:24 -0000

The -34 draft incorporates the proposed resolutions below.  I hope that you can clear your DISCUSS on that basis.

Section 3.3 now does include a reference to an example using the JSON Serialization.

				Thank you,
				-- Mike

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Saturday, October 11, 2014 3:19 PM
> To: Richard Barnes; The IESG
> Cc: 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)
> 
> 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 implementers 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.
> 
> > ----------------------------------------------------------------------
> > 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