Re: [jose] Benoit Claise's No Objection on draft-ietf-jose-jws-signing-input-options-07: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 17 December 2015 08:11 UTC

Return-Path: <bclaise@cisco.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 82DA11B2AC3; Thu, 17 Dec 2015 00:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 S7GRnneLNtLV; Thu, 17 Dec 2015 00:11:39 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74871ACED8; Thu, 17 Dec 2015 00:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1450339899; x=1451549499; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lmvzKGilZ01cKopOxo6lyHb621x8F89M0hiVuoyXRws=; b=CAiprvTBboKfWMQ+GfnKFx+vZGpkd6KdSAGQxA8cejonfEu5YN7Dld1g aaYHBABbyx3m+bFknBbk0PceUlDnvc1Y8cbx9wXPED7KvCHWWB3S40vya pQI+KCpuveiLJCoOAZRaUXM9k1t5/+rGBJqa1AmYKjo4mvqGn0M62cmHS I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CIBwDibXJW/xbLJq1ehAxtu0GECSOCKoNAAoF5AQEBAQEBgQuENAEBAQQjFUABDAQLDgMEAQEDAgUWCAMCAgkDAgECATQJCAYBDAYCAQEXiBQOrDaSAgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGFVYR9hCoRAYM7gUkBBIdaiyyDdoU5hVSCO4FcFoQvgwWQAYN0ZIIRHRaBQT00AYMrgUIBAQE
X-IronPort-AV: E=Sophos;i="5.20,440,1444694400"; d="scan'208";a="609087123"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2015 08:11:35 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBH8BZJc024358; Thu, 17 Dec 2015 08:11:35 GMT
To: Mike Jones <Michael.Jones@microsoft.com>, The IESG <iesg@ietf.org>
References: <20151216221123.7663.35723.idtracker@ietfa.amsl.com> <BL2PR03MB4336F6A3BD8CA6085601AA1F5E00@BL2PR03MB433.namprd03.prod.outlook.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <56726E36.2050305@cisco.com>
Date: Thu, 17 Dec 2015 09:11:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <BL2PR03MB4336F6A3BD8CA6085601AA1F5E00@BL2PR03MB433.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/P5bEJXnoZUUPCn5-IJFgAU_KxkU>
Cc: "stefan.winter@restena.lu" <stefan.winter@restena.lu>, Jim Schaad <ietf@augustcellars.com>, "jose-chairs@ietf.org" <jose-chairs@ietf.org>, "draft-ietf-jose-jws-signing-input-options@ietf.org" <draft-ietf-jose-jws-signing-input-options@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Benoit Claise's No Objection on draft-ietf-jose-jws-signing-input-options-07: (with 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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 08:11:41 -0000

Thanks Mike.

Regards, Benoit
> Thanks for your review, Benoit.  Per my reply to Stefan, I've added the new normative section titled "Using "crit" with "b64"" to specify requirements for situations in which implementations might not understand one another.  As you can see in draft -08 and my reply to Robert Sparks, "crit" is now required in all situations in which the participants might not understand one another.
>
> I've also adopted Stefan's recommendation that "b64" not be included with a value of "true".
>
> 				Thanks again,
> 				-- Mike
>
> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Wednesday, December 16, 2015 11:11 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-jose-jws-signing-input-options@ietf.org; Mike Jones <Michael.Jones@microsoft.com>; Jim Schaad <ietf@augustcellars.com>; jose-chairs@ietf.org; ietf@augustcellars.com; jose@ietf.org; stefan.winter@restena.lu
> Subject: Benoit Claise's No Objection on draft-ietf-jose-jws-signing-input-options-07: (with COMMENT)
>
> Benoit Claise has entered the following ballot position for
> draft-ietf-jose-jws-signing-input-options-07: No Objection
>
> 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 https://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:
> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> As mentioned by Stefan in his OPS DIR review:
> There are coexistence issues between implementations which understand the notion of the "b64" parameter (i.e. implementing this RFC) and those who do not (i.e. all existing JWS implementations).
> The issues are discussed in Security Considerations (second para up until the end). The issues with it are:
>
> * the conclusions are not as satisfactory as they could be.
> Interoperability is either
>
>   - left as an out-of-band and undescribed mechanism ("make sure that only supporting implementations talk to each other")
>   - by explicitly marking support for b64 as critical (IMO the only good
> solution)
>   - modifying the payload so that it contains unparseable characters (which may or may not be possible for the sender depending on the payload characteristics)
>
> * this is placed in Security Considerations while it has actual operational impact on every transmitted message: in essence it states:
> "Sometimes, sender and recipient may misunderstand each other without noticing". Example given in the draft where the actual message is "NDA1"
> while the recipient thinks it was told "405", without a way to notice.
> Even if the misunderstanding is not related to security, it can/will have significant implications for the application.
>
> I believe this can not be left as-is. Luckily, there seems to be an easy way out:
>
> "Whenever the 'b64' header exists and is set to false, the 'crit' header MUST also be present and contain 'b64'."
>
> This, maybe in conjunction with
>
> "When the content is intended to be base64 encoded, the 'b64' header SHOULD NOT be present."
>
> This would make sure that implementations who know nothing of b64 are left alone (there is no unknown extension, there is no criticality in any such extension, and the sender did not intend to make use of the feature => all good). While at the same time for unencoded payloads making deterministically clear that unencoded transmission is happening, and is required to be understood.
>
> This would at the same time make a complex piece of Sec Con go away.
>
>