Re: [OAUTH-WG] deterministic ECDSA (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt)

Neil Madden <neil.madden@forgerock.com> Sat, 05 May 2018 06:24 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0510D12E049 for <oauth@ietfa.amsl.com>; Fri, 4 May 2018 23:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 ggDfdk2FrQH2 for <oauth@ietfa.amsl.com>; Fri, 4 May 2018 23:24:19 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A9F12D775 for <oauth@ietf.org>; Fri, 4 May 2018 23:24:19 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id a137-v6so9312890wme.1 for <oauth@ietf.org>; Fri, 04 May 2018 23:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=iiQhvxrVFSWmvoVL8GAHchWvXTv1Qb8MoHfF6VYpHts=; b=MdZ4mtHVWery2DUc5cokeYeqwqLNchGFOESHPmwy+YoNr0oOSP8W9KiVv3X5eOr9pJ ievIknYi/hdwK9UZrEAq11iW8X41wJKF+xgXKl6IspHjcf3PIlxLG8xixV4DahwoyDq/ 3w1F+LZJudjGMsbNVw9Gm9WcYg/N0B+xlc2KY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=iiQhvxrVFSWmvoVL8GAHchWvXTv1Qb8MoHfF6VYpHts=; b=mEyHaRLbUpjiMVvKaOJYtRo8a5eql6tXUsQkufs2TAHIQMwFijie2N8Z9lkQDRGpqJ i+Z6pcFgBPuLuMPslxCKm4+SLm/hfbuKxJLXPX52O3fF2CMEZTYmF0WKd3sOzRw34E+i doDb2lcJTYDWZu0bcY2vm4P/M5dNg3snxes2IC4YJB2ffL35Zjhuk+s6yVlElWvBuRiA lCNnI0Mei+jyQKRKW8yq3Y1stIo4yWacHsexyHGcyOEyJStgnK0lzcNqPewiTmdsR8jX I6ZxHiRtkyx4FZuCjLEdvgkvwryxNyUnJ8QjUlKcL5XsW6QqhnNsCfpGRIsO4pQReiXl c1Bw==
X-Gm-Message-State: ALQs6tDHo05xGeiPbc3CHpgre+MUK9SvO9a9GucWhNi37C5ZvgYL+NNk DeC+F7WeDp0tt9DkNc3fYNh+9kGG8ww=
X-Google-Smtp-Source: AB8JxZoQuQ9alfL4fDq4AEtPwyhaG+oGtz/F8Kks/9TCOHTIO0BQxb1i1pHvEOnJUOJi54qru0XhMg==
X-Received: by 10.28.143.143 with SMTP id r137mr18237304wmd.103.1525501457672; Fri, 04 May 2018 23:24:17 -0700 (PDT)
Received: from [192.168.1.81] (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id m1-v6sm3369823wma.8.2018.05.04.23.24.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 23:24:16 -0700 (PDT)
Date: Sat, 05 May 2018 07:24:12 +0100
From: Neil Madden <neil.madden@forgerock.com>
To: Brian Campbell <bcampbell@pingidentity.com>, Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Message-ID: <e2a61606-ef68-47fe-8474-a6d4acc52490@Canary>
In-Reply-To: <CA+k3eCRXtbSMMVEq3Fic6qF40+SCSrvPKxYyWJ7x4+GE7Ya-rA@mail.gmail.com>
References: <CA+k3eCRXtbSMMVEq3Fic6qF40+SCSrvPKxYyWJ7x4+GE7Ya-rA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="5aed4e0e_327b23c6_118"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Iur2XWELlgr8ZJZ3dMu6qeTMbPM>
Subject: Re: [OAUTH-WG] deterministic ECDSA (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 May 2018 06:24:23 -0000

I think it’s generally recommended in most situations these days. For instance, use of RFC 6979 is RECOMMENDED in TLS 1.3 - see end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-C.3

Some more recent research suggests you need to be careful of fault attacks in embedded/IoT deployments where attackers with physical access to the chips may be a threat - https://eprint.iacr.org/2017/975.

— Neil

> On Friday, May 04, 2018 at 10:57 pm, Brian Campbell <bcampbell@pingidentity.com (mailto:bcampbell@pingidentity.com)> wrote:
> New in this version of draft-ietf-oauth-jwt-bcp is a rather strong recommendation to use deterministic ECDSA from RFC 6979 (the new text with a SHOULD is copy/pasted below for the lazy among us that might be reading this).
>
> Is this consistent with the general thinking or advice out of the IETF or CFRG these days? RFC6979 talks a lot about it's usefulness in environments without a source of high-quality randomness. Should this here JWT BCP qualify its 'SHOULD' with something about that? Or is deterministic the gold standard recommendation now regardless? I get that it can be used in environments even that have good randomness but I'm wondering if that's truly the expert recommendation? Are there any reasons not to use it or situations where it wouldn't be appropriate?
>
> I don't ask to try and be critical but to try and better understand. As a WG participant, is this the right recommendation? As a maintainer of a JWT/JOSE library that doesn't do deterministic ECDSA (and I suspect isn't particularly unique in that respect), is it something I SHOULD be implementing?
>
>
>
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02#section-3.2 :
> - ECDSA signatures require a unique random value for every message that is signed. If even just a few bits of the random value are predictable across multiple messages then the security of the signature scheme may be compromised. In the worst case, the private key may be recoverable by an attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA using the deterministic approach defined in [RFC6979 (https://tools.ietf.org/html/rfc6979)]. This approach is completely compatible with existing ECDSA verifiers and so can be implemented without new algorithm identifiers being required.
>
> On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer <yaronf.ietf@gmail.com (mailto:yaronf.ietf@gmail.com)> wrote:
> > This new version should address all WGLC comments. Please let us know if there's anything missing.
> >
> > Thanks,
> > Yaron
> >
> >
> > -------- Forwarded Message --------
> > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt
> > Date: Wed, 02 May 2018 01:26:17 -0700
> > From: internet-drafts@ietf.org (mailto:internet-drafts@ietf.org)
> > To: Michael B. Jones <mbj@microsoft.com (mailto:mbj@microsoft.com)>, Yaron Sheffer <yaronf.ietf@gmail.com (mailto:yaronf.ietf@gmail.com)>, Dick Hardt <dick@amazon.com (mailto:dick@amazon.com)>, Michael Jones <mbj@microsoft.com (mailto:mbj@microsoft.com)>
> >
> >
> > A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt
> > has been successfully submitted by Yaron Sheffer and posted to the
> > IETF repository.
> >
> > Name: draft-ietf-oauth-jwt-bcp
> > Revision: 02
> > Title: JSON Web Token Best Current Practices
> > Document date: 2018-05-02
> > Group: oauth
> > Pages: 13
> > URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt
> > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/
> > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02
> > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-02
> >
> > Abstract:
> > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
> > tokens that contain a set of claims that can be signed and/or
> > encrypted. JWTs are being widely used and deployed as a simple
> > security token format in numerous protocols and applications, both in
> > the area of digital identity, and in other application areas. The
> > goal of this Best Current Practices document is to provide actionable
> > guidance leading to secure implementation and deployment of JWTs.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org (http://tools.ietf.org).
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org (mailto:OAuth@ietf.org)
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth