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

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
> To: Michael B. Jones <[e-mail]>, Yaron Sheffer <
> [e-mail]>, Dick Hardt <[e-mail]>, Michael Jones <
> [e-mail]>
>
>
> 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.
>
> The IETF Secretariat
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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._