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

Tero Kivinen <kivinen@iki.fi> Wed, 17 September 2014 07:59 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 13D961A0360; Wed, 17 Sep 2014 00:59:43 -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 4QkUA4JICcyB; Wed, 17 Sep 2014 00:59:41 -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 6D1B31A0353; Wed, 17 Sep 2014 00:59:41 -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 s8H7xct8000475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Sep 2014 10:59:38 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8H7xa0C023908; Wed, 17 Sep 2014 10:59:36 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <21529.16232.880915.215045@fireball.kivinen.iki.fi>
Date: Wed, 17 Sep 2014 10:59:36 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Richard Barnes <rlb@ipv.sx>
In-Reply-To: <CAL02cgQKfQr_dQ=0-oY19G4rmYL3928UWFLBfhDAyspwMU7W9g@mail.gmail.com>
References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <CAL02cgSsi603XL2o4S89pAw64yLv0JRZaDg823uiyuTkm02AHA@mail.gmail.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <CAL02cgQKfQr_dQ=0-oY19G4rmYL3928UWFLBfhDAyspwMU7W9g@mail.gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 6 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GeBrMoe6T_v-QTdyqMjjZMm1zDw
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: Wed, 17 Sep 2014 07:59:43 -0000

Richard Barnes writes:
>     Perhaps, but is there benefits for leaving the alg without protection?
> 
> Simplicity (if you omit protected headers altogether), and
> compatibility with other signed things.  In the sense that you could
> transform one of them into a JWS without re-signing.  This would
> apply, for example, to an X.509 certificate -- just parse the outer
> SEQUENCE, and re-assemble into a JWS with the tbsCertificate as
> payload.  Same security properties that X.509 already has.

Ok, having this kind of information somewhere in the draft would help
to understand the reason. Also having text explaining that is
possible, and that the security properties of this option (i.e. no
problem with PKCS#1, etc... the text you had in the other email). 

> It's also completely unnecessary for PKCS#1 signatures, which are
> the dominant use case today.

I agree.

> In general, I'm opposed to protocols baking in more
> application-specific logic than they need to.  The point of JOSE is
> to describe the cryptographic operation that was performed, and
> carry the relevant bits around.  Its job is not to fix all the
> weaknesses that every algorithm has. 

Yes, but this property might have security issues, so they should be
covered by the security considerations section. 
-- 
kivinen@iki.fi