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

Mike Jones <> Sat, 18 October 2014 23:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E40F1A1A0F; Sat, 18 Oct 2014 16:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9tQx1g_kV-p; Sat, 18 Oct 2014 16:09:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24DF11A19F4; Sat, 18 Oct 2014 16:09:27 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 23:09:27 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 23:09:25 +0000
Received: from (2a01:111:f400:7c10::138) by (2a01:111:e400:1414::48) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Sat, 18 Oct 2014 23:09:24 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 18 Oct 2014 23:09:24 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Sat, 18 Oct 2014 23:09:18 +0000
From: Mike Jones <>
To: Richard Barnes <>
Thread-Topic: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
Thread-Index: AQHP3emqVpLnCgCNb0aC4JUQahHqKJwiVu1wgAeXzACAAXK0QIAK4o4AgABOm4A=
Date: Sat, 18 Oct 2014 23:09:17 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(52604005)(51704005)(97736003)(23676002)(84676001)(230783001)(81156004)(106466001)(77096002)(21056001)(86612001)(92726001)(64706001)(50466002)(85852003)(47776003)(20776003)(120916001)(92566001)(95666004)(4396001)(86362001)(107046002)(87936001)(26826002)(80022003)(46102003)(50986999)(44976005)(33656002)(6806004)(69596002)(68736004)(76482002)(104016003)(85806002)(31966008)(110136001)(2656002)(106116001)(66066001)(85306004)(76176999)(99396003)(93886004)(55846006)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0368E78B5B
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1271;
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Oct 2014 23:09:30 -0000

> > > Section 3.6.
> > > I'm not going to object to "none", even though I think it's a very dangerous
> > > feature because of the risk of confusion between Secured and Unsecured JWS.
> > > But there needs to be stronger guidance:
> > > 1. An implementation SHOULD NOT support "none" unless the implementer
> > > knows that it will be used in application context s that require it.
> > > 2. If an implementation does support "none", then it MUST NOT accept it as part
> > > of generic JWS validation.  Instead, it should require the application to explicitly
> > > signal that an Unsecured JWS is expected for a given validation operation.
> >
> > As discussed in the working group, your concern about applications inappropriately allowing the use of "none" actually is an instance of a more general concern that applications not allow *any* algorithms to be used that are not appropriate in their application contexts.  This concern is already addressed in the specification at the end of Section 5.2 as follows:
> >
> > "Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject the JWS."
> >
> > Since your specific concern is already handled in a more general way, I would like to request that you withdraw this DISCUSS on that basis.  Also, you were one of the contributing authors to the security considerations on this topic in Section 8.5 of JWA (Unsecured JWS Security Considerations), so it's not clear that there's any cause for you to come back with additional wording change requests on this topic at this point.
> >
> > Thanks for reminding me about Section 8.5.  I think I would be satisfied here if the contents of Section 8.5 were just moved up to this section.  That way all of the requirements for implementing "none" will be together.
> Section 3.6 does end with the sentence "See Section 8.5 for security considerations associated with using this algorithm" so implementers are reminded to also pay attention to the security considerations.  If we were to do what you requested, this would be the only algorithm for which the security considerations were included in the algorithm description, rather than in the security considerations section, which would be fairly weird and non-parallel, editorially.
> Actually, "none" is the only algorithm for which there are additional normative requirements in the Security Considerations.  So it actually seems more sensible to move those requirements up. 
> I'm really just asking for a copy/paste here, shouldn't be invasive.  But I do think the level of indirection creates security risk.

I'm OK moving up the three sentences that actually do contain normative requirements.  Those are:

   Implementations that support Unsecured JWS objects MUST NOT accept
   such objects as valid unless the application specifies that it is
   acceptable for a specific object to not be integrity-protected.
   Implementations MUST NOT accept Unsecured JWS objects by default.
   In order to mitigate downgrade attacks, applications MUST NOT signal
   acceptance of Unsecured JWS objects at a global level, and SHOULD
   signal acceptance on a per-object basis.

I'm not OK cluttering up the normative description of the algorithm with the discussion text.  Assuming you're OK leaving the discussion text and "for example" text in 8.5, I think we have a way forward on this one.  Please let me know if that works for you. 

> Again, given that you were an author of 8.5 and seemed fine with the resolution after the extensive discussion then, I'd ask you to clear the DISCUSS on that basis and not request that it be reworked again.

				-- Mike