Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens

Scott Arciszewski <scott@paragonie.com> Fri, 20 April 2018 02:33 UTC

Return-Path: <scott@paragonie.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B5F126D0C for <cfrg@ietfa.amsl.com>; Thu, 19 Apr 2018 19:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paragonie-com.20150623.gappssmtp.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 UsjCFNdiIsOy for <cfrg@ietfa.amsl.com>; Thu, 19 Apr 2018 19:33:21 -0700 (PDT)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 1000212711A for <cfrg@ietf.org>; Thu, 19 Apr 2018 19:33:21 -0700 (PDT)
Received: by mail-ot0-x22f.google.com with SMTP id 77-v6so1971871otd.4 for <cfrg@ietf.org>; Thu, 19 Apr 2018 19:33:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bFV0B9Uq1VCWqAD2uyM2y8BCcdZe8tDznWOg3VeYEDM=; b=YGJiqg9U8KBNhW4UkWEuNH170x1CuxQM36segvpfLyhQkzUBkyN5AAHL0qnl36cc3O dY0ugjZLYGII2uk9cm0us+MPC8ObLsY8E4nOUkFFcAdOFY7qVQxlbcQDny0NqP2OGwSj sdt70Z4A8x4cKAtCd/yishae0fjr80FLRBuRTUVs/FYdGV5P/iPiEZpuGsHXtCXo88p2 3WOhfwF2wTgXsbYhSdPolkmnQZMZ+YaWJdsKsD/m1hjN8hfetY/IfBvYYNmjnFsc89lP Lp8/kOQXNCGb2GUJlJQLnDHPqptDqY1/LOL6Po1uQKWso49Taba2s8x07JB2Zj4TajnK I0tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bFV0B9Uq1VCWqAD2uyM2y8BCcdZe8tDznWOg3VeYEDM=; b=gXMVRcReAS+VxL3FCnM8zOxEjz8FHPSDXy9ZDZ9km6W9iVhYO4tqbTlxDfDnIh4KkG CeLs0Y71FhdlQ1uzzgo6yAaqFc0n09cSRqRP4/zLmqFHVNw8aE9DGGiWvC3hi7/BEv4M RNlLJdKpHpzXlbA/A+X4QbU5now8A2kuxmMBt+DZOAz0VTARLerAQdd3ZSJDFEXoZPde zMCq3j3si4gHVYsgA6F21TBxSXe65SOZHsVO1UdK4auetj2hmniUmt3zJWB1HcfO9m7I WP/kFheIWD+U3Otb0CWeZhpB6la8bbgsvTNG9gs9EUCAFd4tMKvIdPUHx6B8dSPwrtFB uT3g==
X-Gm-Message-State: ALQs6tAVFUxSjgwxBdf7XK6VKO3MAZWQgABagXCF6ehdMdyNwDBXKywC CUdAy151eynLCdr+HzpPeCekvYBqUa6pIFCqjyNSeA==
X-Google-Smtp-Source: AIpwx4+1gNSK3y6Qw9tdXHjyzUP+IOUJmOXiKwTEukHtyp5M/LyJM6qsdBuxqb44PQivOPEvrQCbGPfXOOc0xAdps6w=
X-Received: by 2002:a9d:5e02:: with SMTP id d2-v6mr5888156oti.43.1524191600169; Thu, 19 Apr 2018 19:33:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:55e9:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 19:33:19 -0700 (PDT)
In-Reply-To: <DBC2F048-C949-4362-8FD0-A43A54767B03@gmail.com>
References: <CAKws9z15m6WY+-mz5D01vxB4s-TE7nQN56=ssYt=vz3z4gAj6A@mail.gmail.com> <DBC2F048-C949-4362-8FD0-A43A54767B03@gmail.com>
From: Scott Arciszewski <scott@paragonie.com>
Date: Thu, 19 Apr 2018 22:33:19 -0400
Message-ID: <CAKws9z277JLfv7Pb9wSkJ7zYR8FzoAfiXuFS6Vq0x32-3bWx7Q@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: jose@ietf.org, cfrg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e5e78a056a3e8289"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/G0yVyfoyJoKsJ6mHwV_Beo6HtB8>
X-Mailman-Approved-At: Sat, 28 Apr 2018 09:46:07 -0700
Subject: Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2018 02:33:26 -0000

Hi Neil,

Firstly, your blog post states that ECDH in JOSE is only defined for NIST
> curves. Actually, RFC 8037 [1] defined X25519/X448 for ECDH in JWE and
> EdDSA for JWS.
>
>
That's great. This was not known to me when I wrote the blog post in March
2017.

I'm curious: Which libraries implement RFC 8037 and eschew the foot-gun
public key cryptography protocols?

If RFC 8037 adoption has reached 100% of libraries and protocols that
implement JOSE standards, and none of them speak RSA-PKCS1v1.5 or
non-deterministic ECDSA with a NIST curve anymore, I'll need to reevaluate
my position on JOSE at the ecosystem level. Otherwise, JOSE's legacy of
being an error-prone cryptographic standard is still rather damning at the
ecosystem level, and the only effective means of fixing that is to replace
the entire standard with something not-broken.

​
> ​
> - The basic encryption construction [3] appears (to me at least) to be a
> novel design based on three passes over the message: once to generate a
> pseudorandom nonce in an SIV-like construction (but not actually
> authenticating the message), a second time to encrypt, and then a third
> time to authenticate the cipher text. Is this a well-studied design? What
> security goal is it designed to meet?
>
>
The v1 construction is literally CTR+HMAC. It uses HKDF for key splitting
(which is what HKDF was meant for). It uses SHA384 so only one hash
function needs to be implemented. (SHA384 was chosen due to it being the
best of the SHA2 variants available in e.g. PHP 7.0 that's immune to
length-extension attacks.) Furthermore, v1 uses PSS instead of PKCS1v1.5
because PKCS1v1.5 is a terrible idea.

What you're calling an SIV-like construction is just part of the
nonce/HKDF-salt generation scheme for v1. Its purpose is to add a safeguard
in case someone implements it against an insecure RNG such as OpenSSL's
RAND_bytes() (which is not fork-safe and might repeat outputs, which would
be catastrophic for CTR mode). If an implementation eschewed that and just
did /dev/urandom here, it wouldn't affect much since the nonce provided in
the actual token is what's used to decrypt. As long as HMAC-SHA384 is
collision-resistant, it will serve its purpose of avoiding nonce-reuse
conditions and otherwise isn't that important.

AES-CTR then HMAC-SHA2 is a pretty simple and well-studied construction,
although AES-CBC is more common than AES-CTR. We find it simpler to
implement CTR mode safely in real world systems that only give you ECB mode
out of the box, without introducing e.g. padding-related bugs.

​ Why not just use SIV mode?
>
>
Open up the crypto interfaces exposed in any three of the most used
programming languages on the Internet today. You can be biased and pick
your favorites, as long as they power >= 1% of the Internet and aren't
something totally obscure. Then tell me which among them offer SIV mode.

Protocol v1 literally only exists for systems that use e.g. OpenSSL and
cannot, for political or technical reasons, use something like NaCl,
libsodium, HaCl, etc.

- PASETO still relies on the message to tell it the type of crypto
> algorithms in use: “v1.local” vs “v1.public” vs “v2.local” etc. Isn’t this
> “alg” again, but with a more restricted (and higher-level) set of
> algorithms? I don’t think this is necessary at all - see below for an
> alternative. ​
>
>
There is one advantage to what we're doing here (v1.local vs v2.local) over
what JOSE does: Instead of library designers or users being able to
mix-and-match cryptography protocols, they choose their version and purpose
and the rest of the details are decided for them.

No knobs, no levers, no corner cases where someone accidentally deploys
e=d=1 RSA [1]. Instead, they get one simple, misuse-resistant standard that
solves their needs without any surprises.

​
> ​
> - There are some odd combinations of security levels defined. For
> instance, v1.local uses untruncated HMAC-SHA384 for authentication (384-bit
> tag), while v2.local uses Poly1305 (128-bit tag) - so v2 is actually
> targeting a lower security level for authentication?
>

As said above, this design decision was motivated by having one single hash
function used for all operations. SHA384 was chosen because other
developers might try to badly mimic the design decisions made in PASETO and
I'd rather them choose a hash function that isn't susceptible to
length-extension attacks if they do that.

Truncating the v1 tag hadn't come up before, but it might be worth
considering. The goal is to provide a security level of at least 128 bits
where ever we can. Excess is acceptable as long as it's not killing
performance to do so.

​
> ​
> - XChaCha20 has not been formally published before. While it seems an
> “obvious” translation of XSalsa20 to ChaCha20, I’d prefer that to be
> independently specified (e.g. by CFRG) before being the recommended choice.
> XSalsa20 is already published and well known. ​
>
>
Agreed. ​I​ would be much more comfortable culling XChaCha from our draft
and instead referencing an RFC the CFRG approved. Is there any interest in
doing so?

​
> ​
> - The guidelines in section 3.1 are unclear. For instance, they state that
> long nonces (> 128 bits) satisfy “some degree of nonce-misuse resistance”,
> but they do not - at least not in the sense of misuse-resistant
> authenticated encryption (MRAE). They just make randomly-generated nonces
> less likely to collide. The security goals should be clearly defined here.
> ​
>
>
This is an excellent point. I'll work on clarifying the security goals in
the next draft.

​
> ​
> - The guidelines state that public key encryption should be IND-CCA2, but
> public key encryption is not defined in the spec. It’s not clear that
> IND-CCA2 is the right security goal here, vs e.g. public key authenticated
> encryption as in NaCl. ​
>
>
We don't use public-key encryption at all, so you're right that IND-CCA2
isn't an obvious security goal. However, because PKCS1v1.5 padding is used
both for encryption and signatures, and several attacks [2] [3] that can be
combined [4], I felt it was important to outlaw this error-prone
cryptographic mode and anything similar. If that is erroneous, do have a
better definition to suggest in its stead?

---

Rich,

I disagree that AES-CTR + HMAC-SHA2 (encrypt then MAC) is reason enough to
throw anything away.

[1]: http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1
[2]: http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
[3]: https://www.ietf.org/mail-archive/web/openpgp/current/msg00999.html
[4]: https://robotattack.org

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Apr 19, 2018 at 6:03 PM, Neil Madden <neil.e.madden@gmail.com>
wrote:

> I agree with some of the criticisms of JOSE here, but I have some concerns
> about the proposed replacement.
> ​​
>
> Firstly, your blog post states that ECDH in JOSE is only defined for NIST
> curves. Actually, RFC 8037 [1] defined X25519/X448 for ECDH in JWE and
> EdDSA for JWS.
>
> Thomas Ptacek also had some good observations about weaknesses of the JOSE
> standards [2].
> ​​
>
> Two questions then occur to me:
> 1. Is JOSE fixable or does it need to be replaced entirely?
> 2. If it needs to be replaced, is PASETO a suitable replacement?
>
> I’ll tackle these in reverse order. I find PASETO interesting, but also
> find aspects of the design somewhat confusing:
> ​​
>
> - The basic encryption construction [3] appears (to me at least) to be a
> novel design based on three passes over the message: once to generate a
> pseudorandom nonce in an SIV-like construction (but not actually
> authenticating the message), a second time to encrypt, and then a third
> time to authenticate the cipher text. Is this a well-studied design? What
> security goal is it designed to meet? Why not just use SIV mode?
> ​​
>
> - PASETO still relies on the message to tell it the type of crypto
> algorithms in use: “v1.local” vs “v1.public” vs “v2.local” etc. Isn’t this
> “alg” again, but with a more restricted (and higher-level) set of
> algorithms? I don’t think this is necessary at all - see below for an
> alternative.
> ​​
>
> - There are some odd combinations of security levels defined. For
> instance, v1.local uses untruncated HMAC-SHA384 for authentication (384-bit
> tag), while v2.local uses Poly1305 (128-bit tag) - so v2 is actually
> targeting a lower security level for authentication?
> ​​
>
> - XChaCha20 has not been formally published before. While it seems an
> “obvious” translation of XSalsa20 to ChaCha20, I’d prefer that to be
> independently specified (e.g. by CFRG) before being the recommended choice.
> XSalsa20 is already published and well known.
>
> ​​
> - The guidelines in section 3.1 are unclear. For instance, they state that
> long nonces (> 128 bits) satisfy “some degree of nonce-misuse resistance”,
> but they do not - at least not in the sense of misuse-resistant
> authenticated encryption (MRAE). They just make randomly-generated nonces
> less likely to collide. The security goals should be clearly defined here.
> ​​
>
> - The guidelines state that public key encryption should be IND-CCA2, but
> public key encryption is not defined in the spec. It’s not clear that
> IND-CCA2 is the right security goal here, vs e.g. public key authenticated
> encryption as in NaCl.
>
> So while I appreciate the streamlined design compared to JOSE, there are
> enough non-obvious design decisions here that I am reluctant to immediately
> recommend it as a replacement for JOSE.
>
> But is JOSE fixable instead? I think there is certainly a lot you could do
> to improve it without completely throwing it away and starting again. The
> problem is that old standards never really get thrown away, so we end up
> supporting n+1 standards instead. I think a few basic changes could improve
> the standards considerably:
>
> 1. Deprecating broken/dubious algorithms (like RSA encryption with PKCS#1
> v1.5 padding) and proposing modern and robust replacements (like RFC 8037
> or my own draft for SIV modes [4]).
> 2. Moving the “alg” and “enc” headers out of JWE/JWS and instead into JWK
> so that is the key that determines the algorithm not the message.
> 3. Deprecating all the ways that you can specify a key in a message,
> leaving just “kid”.
>
> I think these changes would go quite a long way to making JOSE more
> robust. It wouldn’t solve everything (and I have more suggestions for
> another time), but it moves in the right direction. Ultimately I would like
> JWE to gravitate towards authenticated encryption in both symmetric and
> public-key settings, and JWS to concentrate on non-repudiation, but that is
> a larger change.
>
> [1] https://tools.ietf.org/html/rfc8037
> [2] https://lobste.rs/s/r4lv76/jwt_is_bad_standard_everyone_
> should_avoid#c_k91fsa
> [3] https://tools.ietf.org/html/draft-paragon-paseto-rfc-00#section-4.3.2
> [4] https://tools.ietf.org/html/draft-madden-jose-siv-mode-02
>
> Regards,
>
> Neil Madden
>
> > On 19 Apr 2018, at 15:13, Scott Arciszewski <scott@paragonie.com> wrote:
> >
> > Dear IETF mailing list members,
> >
> > There have been many real-world failures of the JOSE family of Internet
> Standards since they were published in RFCs 7515-7520.
> >
> > - Accepting {"alg":"none"} in many implementations allowed attackers to
> bypass the protections that JWS were supposed to provide.
> > - Substituting RS256 with HS256 and using the RSA public key as an HMAC
> secret key allowed trivial token forgery.
> > - JWE with ECIES fell to invalid curve attacks.
> >
> > I've outlined these criticisms and more in a post titled "No way JOSE!
> Javascript Object Signing and Encryption is a Bad Standard That Everyone
> Should Avoid" [1] last year.
> >
> > In addition to the critical vulnerabilities in the JOSE standards, there
> are a lot of cryptographic smells to be found, especially in related
> standards. Let me give you a brief, concrete example.
> >
> > Recently, the W3C specification for WebAuthn was circulated on social
> media. Upon closer review, it uses COSE (CBOR Object Signing and
> Encryption-- a JOSE derivative), which requests the registration of two
> classes of public-key signature algorithms [2]:
> >
> > 1. RSA with PCKS1v1.5
> > 2. ECDAA, whose formal definition eschews the use of deterministic
> nonces [3] and thereby fails to provide the protection of e.g. RFC 6979
> >
> > There are a few lessons that I believe we can take away from these facts:
> >
> > 1. User-friendly standards like JOSE are incredibly influential in
> future protocol designs.
> > 2. If the decision to design cryptography protocols and/or decide the
> primitives used is left to library designers and/or users, rather than
> cryptography engineers, they will inevitably choose something dangerous or
> terrifying.
> >
> > There is an elegant solution to this trap we've found ourselves in:
> Design an alternative token standard that avoids all of the design deficits
> that plague the incumbent standard, but is still easy to use for at least
> 90% of the JOSE/COSE use-cases. With that in mind, I'd like to present
> PASETO.
> >
> > The first RFC draft is online [4]. As of this writing, we have 11
> implementations in 10 different programming languages. [5]
> >
> > The biggest change from JWT to PASETO is that, instead of an alg header
> that MUST be understood and processed by implementations in JWT (which
> allows different algorithms to be specified in the attacker-provided token)
> in PASETO we use versioned protocols.
> >
> > * If you're using v1, you're using AES-CTR+HMAC-SHA384 or RSASSA-PSS
> with MGF1+SHA384, SHA384, and e=65537.
> > * If you're using v2, you're using XChaCha20-Poly1305 or Ed25519.
> >
> > Future versions should be defined by cryptography experts.
> >
> > Thank you for your time and please let me know if you have any immediate
> feedback. If you would like to contribute to the next iteration of the RFC
> draft, we're handling this on Github [6].
> >
> > Note: I'm sending this to the JOSE and CFRG mailing lists. We don't yet
> have a Working Group for this project. I'm unsure if a separate one should
> be formed or if an existing one would like to contribute to the review and
> refinement of this proposed Internet Standard.
> >
> > [1]: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-
> is-bad-standard-that-everyone-should-avoid
> > [2]: https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-cose-alg-reg
> > [3]: https://fidoalliance.org/specs/fido-uaf-v1.1-id-
> 20170202/fido-ecdaa-algorithm-v1.1-id-20170202.html#ecdaa-sign
> > [4]: https://datatracker..ietf.org/doc/draft-paragon-paseto-rfc
> > [5]: https://paseto.io
> > [6]: https://github.com/paragonie/paseto/blob/master/docs/RFC/paseto.md
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises​​
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
>
>