Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

"Jim Schaad" <ietf@augustcellars.com> Sun, 13 December 2015 05:11 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B021ACDA9; Sat, 12 Dec 2015 21:11:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 R8JRRw2fX6no; Sat, 12 Dec 2015 21:11:02 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D438E1ACDA6; Sat, 12 Dec 2015 21:11:02 -0800 (PST)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DB97438EF2; Sat, 12 Dec 2015 21:11:01 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, 'Robert Sparks' <rjsparks@nostrum.com>, 'General Area Review Team' <gen-art@ietf.org>, ietf@ietf.org, jose@ietf.org, draft-ietf-jose-jws-signing-input-options@ietf.org
References: <5661E491.9050007@nostrum.com> <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Sat, 12 Dec 2015 21:08:14 -0800
Message-ID: <04f801d13564$4711ddd0$d5359970$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQE/Y1LA5K9DnIsKDNFaOIEnwEthJgKIh1ubn9e9OhA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/fvIZ3LvvIK8zC_4Y7S0PvgKTtMw>
Subject: Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Dec 2015 05:11:05 -0000

Mike,

I think that the text is somewhat tone deaf to the issue that Robert raises,
and which I have said many times.

The question is not how to I make sure it will work, but how do I make sure
that it will fail when it is not supposed to work.  Use of 'crit' does that
quite well.  It is not clear that your favored method 1 would do this.

Jim


> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Saturday, December 12, 2015 6:33 PM
> To: Robert Sparks <rjsparks@nostrum.com>; General Area Review Team <gen-
> art@ietf.org>; ietf@ietf.org; jose@ietf.org;
draft-ietf-jose-jws-signing-input-
> options@ietf.org
> Subject: Re: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
> 06
> 
> Hi Robert.  Thanks for the useful review.  Replies are inline below...
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > Sent: Friday, December 4, 2015 11:08 AM
> > To: General Area Review Team <gen-art@ietf.org>; ietf@ietf.org;
> > jose@ietf.org; draft-ietf-jose-jws-signing-input-options@ietf.org
> > Subject: Gen-Art LC review:
> > draft-ietf-jose-jws-signing-input-options-06
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-jose-jws-signing-input-options-06
> > Reviewer: Robert Sparks
> > Review Date: 4Dec2015
> > IETF LC End Date: 9Dec2015
> > IESG Telechat date: 17Dec2015
> >
> > Summary: Almost ready for publication as Proposed Standard, but with a
> > minor issue that should be addressed before publication.
> >
> > Minor issues:
> >
> > This document explicitly provides a way for interoperability to fail,
> > but does not motivate _why_ leaving this failure mode in the protocol
> > is a good tradeoff.
> >
> > Specifically, as the security considerations section points out, it is
> > possible for an existing implementation to receive a JWS that has
> > b64=false, which it will ignore as an unknown parameter, and (however
> > unlikely) successfully decode the payload, and hence believe it has a
> > valid JWS that is not what was sent.
> >
> > The idea that this failure can be avoided by making sure the endpoints
> > all play nice through some unspecified agreement is dangerous.
> > Specifically, I don't think you can rule out the case that the JWS
> > escapes the controlled set of actors you are positing in option 1 from
> > the list in the security considerations..
> >
> > I would have been much more comfortable with a consensus to require
'crit'.
> > (Count me in the rough if this proceeds with crit being optional).
> >
> > I assume there is a strong reason to allow for option 1. Please add
> > the motivation for it to the draft, and consider adding a SHOULD use
'crit'
> > requirement if option 1 remains.
> 
> It's a reasonable request to have the draft say why "crit" isn't required.
My
> working draft adds the following new paragraph at the end of the security
> considerations section to do this.  Unless I hear objections, I'll plan on
publishing
> an updated draft with the paragraph shortly.
> 
> "Note that methods 2 and 3 are sufficient to cause JWSs using this
extension to
> be rejected by implementations not supporting this extension but they are
not
> sufficient to enable JWSs using this extension to be successfully used by
> applications. Thus, method 1 - requiring support for this extension - is
the
> preferred approach and the only means for this extension to be practically
useful
> to applications. Method 2 - requiring the use of <spanx
> style="verb">crit</spanx> - while theoretically useful to ensure that
confusion
> between encoded and unencoded payloads cannot occur, is not particularly
> useful in practice, since method 1 is still required for the extension to
be usable.
> When method 1 is employed, method 2 doesn't add any value and since it
> increases the size of the JWS, its use is not required by this
specification."
> 
> > Nits/editorial comments:
> >
> > In the security considerations, the last sentence of the first
> > paragraph needs to be simplified. I suggest replacing it with:
> >
> > "It then becomes the responsibility of the application to ensure that
> > payloads only contain characters that will not cause parsing problems
> > for the serialization used, as described in Section 5. The application
> > also incurs the responsibility to ensure that the payload will not be
> > modified during retransmission.
> 
> I have simplified this in the manner that you suggested.
> 
> 				Thanks again,
> 				-- Mike
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose