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

[Neil Madden]

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 
> mailto:bcampb...@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  (mailto:yaronf.i...@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-dra...@ietf.org (mailto:internet-dra...@ietf.org)
> > To: Michael B. Jones mailto:m...@microsoft.com)>, 
> > Yaron Sheffer mailto:yaronf.i...@gmail.com)>, Dick 
> > Hardt mailto:d...@amazon.com)>, Michael Jones 
> > mailto:m...@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. 

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

[Brian Campbell]

AFAIK, Tim McLean was the first to bring the HMAC/RSA switching attack to
the attention of JWS/JWT implementers -
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Perhaps he should be acknowledged similar to how Antonio is for the invalid
point attack?

I've also provided a little (admittedly very little) review and feedback on
the draft...



On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer  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-dra...@ietf.org
> To: Michael B. Jones , Yaron Sheffer <
> yaronf.i...@gmail.com>, Dick Hardt , Michael Jones <
> m...@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.
>
> The IETF Secretariat
>
> ___
> OAuth mailing list
> 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

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

[Brian Campbell]

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
].  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  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-dra...@ietf.org
> To: Michael B. Jones , Yaron Sheffer <
> yaronf.i...@gmail.com>, Dick Hardt , Michael Jones <
> m...@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.
>
> The IETF Secretariat
>
> ___
> OAuth mailing list
> 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

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

[Brian Campbell]

Wearing my editor's hat here (did I do that right?) and looking to bring
this to a close so the draft can proceed - I don't see a consensus for
additional confirmation methods in this draft.

On Tue, May 1, 2018 at 3:08 AM, Neil Madden 
wrote:

> JOSE and many other specs have allowed algorithms to be specified at
> multiple security levels: a baseline 128-bit level, and then usually 192-
> and 256-bit levels too. It seems odd that a draft that is ostensibly for
> high security assurance environments would choose to only specify the
> lowest acceptable security level, especially when the 256-bit level has
> essentially negligible overhead. (OK, ~60 bytes additional overhead in a
> JWT - I’d be surprised if that was a deal breaker though).
>
> Still, if the consensus of the WG is that this is not worth it, then I
> don’t want to delay the draft any further. I can always submit a 2 line RFC
> in future to add a SHA-512 confirmation method.
>
> — Neil
>
> > On 30 Apr 2018, at 23:58, John Bradley  wrote:
> >
> > We allow for new thumbprint algorithms to be defined and used with this
> spec.
> > I think that we all agree that is a good thing.
> >
> > The question is if we should define them here or as part of JWT/CWT
> based on broader demand.
> >
> > Including them in this document may be a distraction in my opinion.
>  There is no attack against SHA256 with a short duration token/key (days)
> that is better solved by using a long duration token/key (years) with a
> longer hash.
> >
> > That said it woiulden't like me.  I just think it will distract people
> in the wrong direction.
> >
> > John B.
> >
> >> On Apr 30, 2018, at 7:23 PM, Neil Madden 
> wrote:
> >>
> >> Responses inline again.
> >>
> >> On Mon, 30 Apr 2018 at 19:44, John Bradley  wrote:
> >> Inline.
> >>
> >>
> >>> On Apr 30, 2018, at 12:57 PM, Neil Madden 
> wrote:
> >>>
> >>> Hi John,
> >>>
>  On 30 Apr 2018, at 15:07, John Bradley  wrote:
> 
>  I lean towards letting new certificate thumbprints be defined
> someplace else.
> 
>  With SHA256, it is really second preimage resistance that we care
> about for a certificate thumbprint, rather than simple collision
> resistance.
> >>>
> >>> That’s not true if you consider a malicious client. If I can find any
> pair of certificates c1 and c2 such that SHA256(c1) == SHA256(c2) then I
> can present c1 to the AS when I request an access token and later present
> c2 to the protected resource when I use it. I don’t know if there is an
> actual practical attack based on this, but a successful attack would
> violate the security goal implied by the draft: that that requests made to
> the protected resource "MUST be made […] using the same certificate that
> was used for mutual TLS at the token endpoint.”
> >>>
> >>> NB: this is obviously easier if the client gets to choose its own
> client_id, as it can find the colliding certificates and then sign up with
> whatever subject ended up in c1.
> >>>
> >>
> >> Both C1 and C2 need to be valid certificates, so not just any collision
> will do.
> >>
> >> That doesn’t help much. There’s still enough you can vary in a
> certificate to generate collisions.
> >>
> >> If the client produces C1 and C2 and has the private keys for them, I
> have a hard time seeing what advantage it could get by having colliding
> certificate hashes.
> >>
> >> Me too. But if the security goal is proof of possession, then this
> attack (assuming practical collisions) would break that goal.
> >>
> >>
> >> If the AS is trusting a CA, the attacker producing a certificate that
> matches the hash of another certificate so that it seems like the fake
> certificate was issued by the CA, is an attack that worked on MD5 given
> some predictability.  That is why we now have entropy requirements for
> certificate serial numbers, that reduce known prefix attacks.
> >>
> >> The draft allows for self-signed certificates.
> >>
> >> Second-preimage Resistance is being computationaly infusible to find a
> second preimage that has the same output as the first preimage.   The
> second preimage strength for SHA256 is 201-256bits and collision resistance
> strength is 128 bits.  See Appendix A of https://nvlpubs.nist.gov/
> nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf if you want to
> understand the relationship between message length and second Preimage
> resistance.
> >>
> >> RFC 4270 is old but still has some relevant info.
> https://tools.ietf.org/html/rfc4270
> >>
> >> Think of the confirmation method as the out of band integrity check for
> the certificate that is presented in the TLS session.
> >>
> >> This is all largely irrelevant.
> >>
>  MD5 failed quite badly with chosen prefix collision attacks against
> certificates (Thanks to some X.509 extensions).
>  SHA1 has also been shown to be vulnerable to a PDF chosen prefix
> attack (http://shattered.io)
> 
>  The reason NIST pushed for development of SHA3 was concern that a
> preimage attack might eventuall