Re: [jose] đź”” WGLC of draft-ietf-cose-webauthn-algorithms

Benjamin Kaduk <kaduk@mit.edu> Mon, 23 September 2019 17:37 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23AB1208D7; Mon, 23 Sep 2019 10:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 ikk5Ui4n835k; Mon, 23 Sep 2019 10:37:20 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2BA2E120914; Mon, 23 Sep 2019 10:37:20 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8NHb7n4018715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 13:37:10 -0400
Date: Mon, 23 Sep 2019 10:37:07 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Jim Schaad <ietf@augustcellars.com>, "cose@ietf.org" <cose@ietf.org>, "jose@ietf.org" <jose@ietf.org>, ivaylo petrov <ivaylo@ackl.io>
Message-ID: <20190923173707.GM6424@kduck.mit.edu>
References: <CAJFkdRzEF0wh9-H4dDNQeUHVd_VD8KKv1jOJ7BWs+bKN2e6gBQ@mail.gmail.com> <CAJFkdRy6Bs77gFGG0QGMC1fe_niQC6Of7_2Z8+jjYzpWkuMDBQ@mail.gmail.com> <465EE321-1595-4453-8D4E-E3A6A457C86E@forgerock.com> <012001d56fc0$1fb30e90$5f192bb0$@augustcellars.com> <F6FF776D-FFF9-4330-8A6B-81F783D990C2@forgerock.com> <013c01d56fc8$56cb8b20$0462a160$@augustcellars.com> <MN2PR00MB0576AB42D6324A7F1FFD581EF58B0@MN2PR00MB0576.namprd00.prod.outlook.com> <6D55D5B5-0F0C-4674-92CD-61D5CA25FBC5@forgerock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6D55D5B5-0F0C-4674-92CD-61D5CA25FBC5@forgerock.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/0oWpy5pCwZsQxX3ANRcEL_jsoeI>
Subject: Re: [jose] đź”” WGLC of draft-ietf-cose-webauthn-algorithms
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2019 17:37:32 -0000

On Sat, Sep 21, 2019 at 11:47:53AM +0100, Neil Madden wrote:
> On 21 Sep 2019, at 01:44, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
> > 
> > RSA SHA-1 is used by TPMs, which produce attestations used by W3C WebCrypto.  That can’t be changed.  That’s why an algorithm identifier is needed for it.  It’s use is prohibited for new applications but TPMs are an existing application.  I can work to make this clearer when resolving the WGLC comments.
> 
> I think clarifying the text along those lines would help a lot. It is worrying that these TPMs have to continue to use a known weak signature method and they apparently cannot be changed, but at least with the MUST NOT you give people a clue that this is something they want to run away from pretty quickly.
> 
> >  
> > As for secp256k1, the “ES256K” algorithm is registered, whose definition is “ECDSA using secp256k1 curve and SHA-256”.  That’s only for signing.  The draft is currently silent on whether the registered curve can also be used for other things.  I think that’s how it should be, unless there are security reasons to the contrary.
> 
> Well section 4.4 registers secp256k1 as a JWK Elliptic Curve so it will be usable with the existing ECDH-ES family of algorithms without any additional registrations. There *are* some security concerns about using secp256k1 outside of signatures - see e.g. [1] which lists the theoretical problems with the curve. In particular, fast implementations of scalar multiplication (used in ECDH) for secp256k1 are not constant time making it a riskier choice for ECDH than for ECDSA. As far as I'm aware though, that just puts it in the same category as the other NIST/SECG standard curves that are already registered for JOSE. So I'm not against it being available for both JWS and JWE usage, I'd just like that to be an explicit documented decision rather than an accident.

I'm also inclined to agree that making an explicit statement is preferred;
I have less-strong feelings about whether that statement is to allow or
disallow the usage.

-Ben

> [1]: https://crypto.stackexchange.com/a/68286/26028 <https://crypto.stackexchange.com/a/68286/26028> 
> 
> -- Neil

> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose