Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31

Tero Kivinen <kivinen@iki.fi> Tue, 16 September 2014 08:51 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE051A00EB; Tue, 16 Sep 2014 01:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level:
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_NEUTRAL=0.779] 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 um9tn9AyQNLW; Tue, 16 Sep 2014 01:51:06 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2091F1A0113; Tue, 16 Sep 2014 01:51:05 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8G8p2gZ023231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Sep 2014 11:51:02 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8G8p2uv009477; Tue, 16 Sep 2014 11:51:02 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21527.63989.999440.801542@fireball.kivinen.iki.fi>
Date: Tue, 16 Sep 2014 11:51:01 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Richard Barnes <rlb@ipv.sx>
In-Reply-To: <CAL02cgSsi603XL2o4S89pAw64yLv0JRZaDg823uiyuTkm02AHA@mail.gmail.com>
References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <CAL02cgSsi603XL2o4S89pAw64yLv0JRZaDg823uiyuTkm02AHA@mail.gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 22 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hjDrIzhnDZWv7BHflZQ0Ujv9lTQ
Cc: "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>, "iesg@ietf.org" <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature.all@tools.ietf.org" <draft-ietf-jose-json-web-signature.all@tools.ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Sep 2014 08:51:09 -0000

Richard Barnes writes:
>>>     1) "alg" and Protected Header
>>>    
>>>     Question: Shouldn't the "alg" header parameter be protected by
>>>     the signature, i.e. wouldn't it make sense to say MUST be in
>>>     the "Protected Header"?
>>>    
>>>     I think the draft needs text saying something about the
>>>     situation where "alg" is not in "Protected Header" in the
>>>     security sections section. I.e. either say, that it has been
>>>     analyzed that there is no problem even when the "alg" is not
>>>     protected, and reference to such analysis, or otherwise add
>>>     text/warning that it MUST/SHOULD be in the "Protected Header".
>>>     I do not know enough about the proposed signature algorithms
>>>     to know which one is true, especially as there might be new
>>>     algorithms in the future.
>>>    
>>     Richard Barnes, do you want to answer this one?  You were the
>>     primary advocate for allowing the algorithm to be unprotected
>>     in the JSON Serialization.
>>    
>>     As I recall, the motivation had to do with the fact that, by
>>     default, CMS does not protect the algorithm (although it was
>>     later extended to enable it to be protected).  Some others in
>>     the working group thought that having unprotected algorithms
>>     was a bad idea, in line with your comment above.
>
> The only need for protection of the "alg" value is to prevent algorithm
> substitution attacks, as discussed in RFC 6211.
> https://tools.ietf.org/html/rfc6211
> 
> These attacks are fairly limited in their applicability, since they require
> that:
>  * The attacker is able to compute an input that is valid for the signature
> using a different, weaker algorithm
>  * The attacker's input is valid according to whatever application rules are
> being applied
>  * A relying party will accept the weaker algorithm
> 
> Given all those criteria, it seems reasonable that some signers
> might regard algorithm substitution attacks as an acceptable risk. 

Perhaps, but is there benefits for leaving the alg without protection? 

> For example, in an application that set explicit minimum algorithm
> requirements (e.g., SHA-3 only!), there may be no risk of a relying
> party accepting the weaker algorithm.  Or the application payload
> might have low enough entropy that it's impossible to find a valid
> forged input.
> 
> And if an application is concerned about algorithm substitution
> attacks, it can protect itself by including the algorithm in the
> payload, as X.509 does.

Having this kind of options which might or might not have security is
usually bad. So I would suggest that unless there is use case or real
reason why the alg should NOT be protected all the time, make it
protected always. 

> I would be happy to have some advisory text in the security
> considerations, but I don't think this rises to the level of
> SHOULD/MUST.

I hate to be there in ten years, when someone finds out problems with
this prorotocol, as someone decided to add some new algorithms, and
someone then decided to use the feature include, i.e. having alg
unprotected, and then the combination suddenly causes problems...

So if there is no reason to keep it that way, I would be much more
happy to say that it must be protected always.
-- 
kivinen@iki.fi