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

[Neil Madden <[e-mail]>]

Comments inline below.

> On 20 Apr 2018, at 03:33, Scott Arciszewski <[e-mail]> wrote:
> 
> 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.

I think you are overestimating the effectiveness of this strategy. Unfortunately, insecure implementations of old standards don’t go away because you introduce a new standard.

> 
> >​ ​- 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.

Don’t get me wrong, I think this is a nice idea, but it’s also sufficiently novel that I don’t feel comfortable saying that PASETO v1.local is “just” CTR+HMAC with a few minor tweaks. The HMAC key for the GetNonce() function is coming from the PRNG that you do not trust because it may be biased, poorly designed, etc. If you look at the design of HKDF, it puts potentially biased source key material in the (non-key) input to HMAC and uses either a fixed/empty constant or an (unbiased) random salt as the key. Part of the rationale is given on page 19 of [1]:

“[…] PRFs are specifically designed to remain secure even when the inputs (except for the key) are fully known and correlated, or even adversarially chosen.”

So what can we conclude about the pseudorandom collision resistance of the output of HMAC when the *key* comes from a potentially biased/untrusted source? I’m not a cryptographer, so maybe that is still fine, but I don’t know if you could prove it without making non-standard assumptions about HMAC.

[1] https://eprint.iacr.org/2010/264.pdf

> 
> 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.

From a quick survey:

 - OpenSSL is adding support for AES-SIV [2], apparently because it is planned to be mandatory to implement for NTP security [3].
 - BoringSSL supports AES-GCM-SIV [4] (admittedly this is not quite a straightforward application of SIV mode).
 - Google Tink supports AES-SIV [5] on Java (& Android) with Go, C++, Objective-C in development/planned (I believe), and Javascript and C# ports “in the works".

[2] https://github.com/openssl/openssl/pull/3540
[3] https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-11.html
[4] https://github.com/google/boringssl/blob/master/include/openssl/aead.h
[5] https://github.com/google/tink/blob/master/doc/PRIMITIVES.md#deterministic-authenticated-encryption-with-associated-data

> 
> 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.

AES-SIV itself is a relatively straight-forward composition of AES-CMAC (or another MAC) and AES-CTR, which are widely available building blocks.

> 
> > - 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.

Right, but you could write an RFC that proposes 4 new JOSE algorithms: “v1.local”, “v1.public”, “v2.local”, “v2.public” and marks all others (and associated headers) as prohibited. Wouldn’t that be pretty similar to the core of PASETO? The fundamental problem with “alg” in JOSE is that it requires you to trust the message to tell you what algorithm to use to validate that message. PASETO makes exactly the same mistake, it just has a much better (and much smaller) algorithm selection. 

[snip]

I think the work you are doing on PASETO is valuable and has a lot of nice ideas. I would also say that is already better than JOSE as it currently is, but I’m not sure it is the best replacement.

Kind regards,

Neil