Return-Path: 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 2D4A41A8F50; Tue, 30 Sep 2014 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cZrN_L23cR6Y; Tue, 30 Sep 2014 14:00:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D711A8AB3; Tue, 30 Sep 2014 13:59:35 -0700 (PDT) Received: from BY2PR03CA079.namprd03.prod.outlook.com (10.141.249.52) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 20:59:33 +0000 Received: from BL2FFO11FD046.protection.gbl (2a01:111:f400:7c09::135) by BY2PR03CA079.outlook.office365.com (2a01:111:e400:2c5d::52) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 20:59:33 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD046.mail.protection.outlook.com (10.173.161.208) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 20:59:33 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.218]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Tue, 30 Sep 2014 20:58:50 +0000 From: Mike Jones To: John Bradley Thread-Topic: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33 Thread-Index: AQHP2mhILPxPTyEuvU2oGKNSsFOQjZwZ+E6wgAAWzYCAAAflAIAABKAAgAAGAACAAAlLgA== Date: Tue, 30 Sep 2014 20:58:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAA6CC2@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <23AB1ACB-02B2-4E82-A832-E89E61795C85@vigilsec.com> <4E1F6AAD24975D4BA5B16804296739439BAA578E@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA6CC2TK5EX14MBXC288r_" 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)(438002)(189002)(199003)(24454002)(377454003)(15202345003)(64706001)(106116001)(4396001)(16236675004)(76482002)(104016003)(2656002)(99396003)(110136001)(230783001)(20776003)(85306004)(93886004)(95666004)(33656002)(84676001)(55846006)(512954002)(106466001)(26826002)(84326002)(81156004)(19625215002)(107046002)(19300405004)(92726001)(76176999)(71186001)(50986999)(92566001)(44976005)(80022003)(87936001)(86612001)(97736003)(46102003)(19580395003)(31966008)(54356999)(10300001)(86362001)(19580405001)(120916001)(21056001)(15975445006)(6806004)(77096002)(85852003)(66066001)(68736004)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; 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:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0350D7A55D 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/86jjtIc3HotKI7Vh1AAeNdFDZlk Cc: IETF , IETF Gen-ART , Russ Housley , Dave Cridland , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33 X-BeenThere: jose@ietf.org 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: Tue, 30 Sep 2014 21:00:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BAA6CC2TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, to move this discussion along on a concrete basis, as an expert in th= e subject matter, could you write a proposed security considerations subsec= tion that explains the conditions under which an exception to the MUST woul= d be OK? Then we could evaluate in a concrete way whether we think the spe= cification is better with language like "MUST use TLS unless the conditions= described in Section X.Y are met" or better just requiring TLS to keep thi= ngs simple. It would be good if you also expanded on the trust model comments you made = earlier in the thread and that we discussed on the phone. Thanks much= , -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, September 30, 2014 1:15 PM To: Dave Cridland Cc: IETF; IETF Gen-ART; Russ Housley; Mike Jones; jose@ietf.org; draft-ietf= -jose-json-web-signature.all@tools.ietf.org Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33 The attack is not possible if the receiver validates the host from the x5u = against the certificate CN and validates the path, otherwise any valid cer= tificate would work, as long as it chains to a valid root. Yes we could explain that that the client could limit itself to a specific = root or bridge and use the CN or DN for the identity of the signer. So yes it is possible to make an exception to the MUST but explaining how t= o do that safely is not trivial, and may cause more harm than good. John B. On Sep 30, 2014, at 4:53 PM, Dave Cridland > wrote: On 30 September 2014 20:37, John Bradley > wrote: I agree, the likelihood of the application correctly walking the path and v= alidating the chain is very small. I think the likelihood of the application being *able* to is small given th= e scope - however if it can, we should assume that it will. I strongly prefer leaving it a MUST use TLS and validate the server per RFC= 6125. The other thing to note is that the CN of the cert is not in the header. I= f TLS is not used an attacker could simply modify the DNS to retrieve any v= alid certificate and use that to sign. Whilst I agree there's a range of attacks possible against non-validating c= lients - although "the CN of the cert" sets my teeth on edge - an attacker = cannot do these if the application performs path validation and checks the = key matches. "SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and= if there exist perfectly reasonable cases where this particular MUST can b= e ignored, then by insisting on a MUST here we are simply weakening the emp= hasis that all other RFC 2119 language has in this document. "MUST unless you do X" is a compromise I'd be happy with, although that is = basically what "SHOULD" means. Certainly this does require the rationale be documented in any case. Dave. --_000_4E1F6AAD24975D4BA5B16804296739439BAA6CC2TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John, to move this discus= sion along on a concrete basis, as an expert in the subject matter, could y= ou write a proposed security considerations subsection that explains the conditions under which an exception to the MUST would be OK?&= nbsp; Then we could evaluate in a concrete way whether we think the specifi= cation is better with language like “MUST use TLS unless the conditio= ns described in Section X.Y are met” or better just requiring TLS to keep things simple.

 <= /p>

It would be good if you a= lso expanded on the trust model comments you made earlier in the thread and= that we discussed on the phone.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Thanks much,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: jose [= mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, September 30, 2014 1:15 PM
To: Dave Cridland
Cc: IETF; IETF Gen-ART; Russ Housley; Mike Jones; jose@ietf.org; dra= ft-ietf-jose-json-web-signature.all@tools.ietf.org
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signa= ture-33

 

The attack is not possible if the receiver validates= the host from the x5u against the certificate CN and validates the path, &= nbsp;otherwise any valid certificate would work, as long as it chains to a = valid root.

 

Yes we could explain that that the client could limi= t itself to a specific root or bridge and use the CN or DN for the identity= of the signer.  

 

So yes it is possible to make an exception to the MU= ST but explaining how to do that safely is not trivial, and may cause more = harm than good.

 

John B.

On Sep 30, 2014, at 4:53 PM, Dave Cridland <dave@cridland.net> wrote:=



 

 

On 30 September 2014 20:37, John Bradley <ve7jtb@ve7jtb.com> w= rote:

I agree, the likelihood of the application correctly= walking the path and validating the chain is very small.  =

 

 

I think the likelihood of the application being *abl= e* to is small given the scope - however if it can, we should assume that i= t will.

 

I strongly prefer leaving it a MUST use TLS and vali= date the server per RFC 6125.

 

The other thing to note is that the CN of the cert i= s not in the header.  If TLS is not used an attacker could simply modi= fy the DNS to retrieve any valid certificate and use that to sign.

 

 

Whilst I agree there's a range of attacks possible a= gainst non-validating clients - although "the CN of the cert" set= s my teeth on edge - an attacker cannot do these if the application perform= s path validation and checks the key matches.

 

"SHOULD" and "MUST" are not a st= ick to beat the unthinking implementer, and if there exist perfectly reason= able cases where this particular MUST can be ignored, then by insisting on = a MUST here we are simply weakening the emphasis that all other RFC 2119 language has in this document.

 

"MUST unless you do X" is a compromise I'd= be happy with, although that is basically what "SHOULD" means.

 

Certainly this does require the rationale be documen= ted in any case.

 

Dave.

 

--_000_4E1F6AAD24975D4BA5B16804296739439BAA6CC2TK5EX14MBXC288r_--