Re: [jose] Towards a More Secure JOSE Standard

[Paragon Initiative Enterprises Security Team <[e-mail]>]

On Wed, Mar 29, 2017 at 3:29 PM, Nathaniel McCallum <[e-mail]>
wrote:

> On Wed, Mar 29, 2017 at 2:36 PM, Paragon Initiative Enterprises
> Security Team <[e-mail]> wrote:
> > On Wed, Mar 29, 2017 at 2:22 PM, Justin Richer <[e-mail]> wrote:
> >>
> >> If the problem is substituting “alg: RS256” with “alg: HS256” or the
> like,
> >> how is that any different from substituting “mode: ps” with “mode: sa”?
> >> There have been some reasonable arguments for removing the algorithm
> >> selection from the JOSE package, but this proposal doesn’t do that.
> Instead,
> >> it simply defines *new* headers for algorithm selection. Ergo, unless
> I’m
> >> missing a key point here, this is just kicking things down the road a
> little
> >> bit.
> >>
> >>  — Justin
> >>
> >> On Mar 29, 2017, at 11:19 AM, Paragon Initiative Enterprises Security
> Team
> >> <[e-mail]> wrote:
> >>
> >> Hello,
> >>
> >> We've outlined some suggestions to make a JOSE replacement/upgrade more
> >> secure. Our suggestions are outlined at
> >> https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c
> 03,
> >> but I have mirrored them below.
> >>
> >> Changes to JOSE that will prevent insecurity
> >>
> >> Deletions
> >>
> >> JWS and JWE
> >>
> >> Drop the alg header
> >>
> >> Neither JOSE users nor JOSE library designers should be required to
> >> understand cryptography primitives. At a lower level, this can lead to
> badly
> >> implemented primitives. On a higher level, this can lead to reasoning by
> >> lego.
> >>
> >> For all the reasons outlined here and here, the alg header (and
> algorithm
> >> agility in its entirety) should be considered harmful.
> >>
> >> JWE
> >>
> >> Drop the enc header
> >>
> >> For the same reason we're dropping the alg header, we should drop the
> enc
> >> header.
> >>
> >> Consider dropping the zip header
> >>
> >> As we've seen with CRIME and BREACH, as well as this error oracle attack
> >> against iMessage, compression can introduce side-channels that totally
> >> undermine confidentiality.
> >>
> >> This one is less of a hard-and-fast requirement to make JOSE secure,
> but I
> >> still strongly recommend it.
> >>
> >> Additions
> >>
> >> JWS and JWE
> >>
> >> New header: ver (version)
> >>
> >> Instead of letting library developers and users mix-and-match
> cryptography
> >> algorithms, the only choice they should be given is, "Which version are
> we
> >> using?" Versions can look like this:
> >>
> >> Version 1:
> >>
> >> HMAC-SHA256 for shared-key authentication
> >> AES-128-CBC + HMAC-SHA256 in Encrypt-then-MAC mode for shared-key
> >> encryption
> >> RSA-OAEP with MGF1-SHA256 and e=65537 + AES-128-CBC in KEM+DEM for
> >> public-key encryption, min. key size: 2048-bit
> >> RSASSA-PSS with MGF1-SHA256 and e=65537 for public-key digital
> signatures,
> >> min. key size: 2048-bit
> >>
> >> Version 2:
> >>
> >> HMAC-SHA256 for shared-key authentication
> >> AES-256-GCM for shared-key encryption
> >> ECDH over secp256r1 (NIST P-256) + AES-256-GCM for public-key encryption
> >>
> >> Libraries must verify that the point is on the curve
> >>
> >> ECDSA over secp256r1 (NIST P-256), adhering to RFC 6979 (deterministic
> >> ECDSA), for public-key digital signatures
> >>
> >> Version 3:
> >>
> >> HMAC-SHA512-256 for shared-key authentication
> >>
> >> As per NaCl, this is HMAC-SHA-512 truncated to 256 bits, not
> >> HMAC-SHA-512/256.
> >>
> >> Xsalsa20poly1305 for shared-key encryption
> >> X25519 + Xsalsa20poly1305 for public-key encryption
> >> Ed25519 for public-key digital signatures
> >>
> >> Libraries that support version 3 SHOULD NOT support version 1.
> >>
> >> New header: mode
> >>
> >> Only four options (case-insensitive):
> >>
> >> se = Shared-key Encryption
> >> sa = Shared-key Authentication
> >> pe = Public-key Encryption
> >> ps = Public-key digital Signatures
> >>
> >>
> >> Kind regards,
> >>
> >> Security Team
> >> Paragon Initiative Enterprises
> >> _______________________________________________
> >> jose mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/jose
> >>
> >>
> >
> > Hi,
> >
> >> If the problem is substituting “alg: RS256” with “alg: HS256” or the
> like,
> >> how is that any different from substituting “mode: ps” with “mode: sa”?
> >
> >
> > There are more problems than the RS256/HS256 critical vulnerability from
> > 2015, but nonetheless, you raise a good point:
> >
> > The mode should be decided out-of-band, not supplied by the attacker.
> >
> > Therefore, the mode header must be made optional (i.e. it's purely
> > informational) and implementations should be encouraged to only operate
> in
> > one mode at a time (i.e. not decided by the message they receive).
> >
> >> There have been some reasonable arguments for removing the algorithm
> >> selection from the JOSE package, but this proposal doesn’t do that.
> Instead,
> >> it simply defines *new* headers for algorithm selection. Ergo, unless
> I’m
> >> missing a key point here, this is just kicking things down the road a
> little
> >> bit.
> >
> >
> > The previous standard allowed people to choose which hash function,
> which of
> > the NIST P-curves, etc. to use. The new proposal only allows for one
> > cipher/algorithm per use-case. These algorithm decisions should be made
> by
> > experts and given as non-tweakable, hard-coded configuration options.
> There
> > is no "a little of column A, a little of column B", you either use
> version 2
> > or version 3.
> ​​
>
> But the attacker still gets to choose what version to lie about.
> Implementers will still have to verify that the expected algorithm (as
> defined implicitly by the version) matches the inputs. Failure to
> check inputs has been the cause of all the major vulnerabilities. This
> plan adds precisely no additional security but comes with great cost
> for implementers.
>
> The bottom line is that implementers of JOSE need to know what they're
> doing. The expectation that someone can write a JOSE library without
> understanding cryptographic primitives is unrealistic.
>

​Nathaniel,

​
> ​But the attacker still gets to choose what version to lie about.

Implementers will still have to verify that the expected algorithm (as

defined implicitly by the version) matches the inputs.
> ​​
> ​​
> Failure to
> check inputs has been the cause of all the major vulnerabilities.
> ​​
> This
> plan adds precisely no additional security but comes with great cost

for implementers.​
> ​


​I'd like to unpack your claims here.

​
> ​
> ​
> ​But the attacker still gets to choose what version to lie about.

Implementers will still have to verify that the expected algorithm (as

defined implicitly by the version) matches the inputs.


​Let's look at version 3 of the original email:

   - HMAC-SHA-512-256: 32 byte signature
   - Ed25519: 64 byte signature (RFC 8032 for reference)​
   - XSalsa20Poly1305: [ciphertext] + [16 byte authentication tag]
   - X25519 + XSalsa20Poly1305: [32 byte ephemeral X25519 public key] +
   [Ciphertext] + [16 byte authentication tag]

The respective libsodium functions here would be: crypto_auth(),
crypto_sign(), crypto_secretbox(), and crypto_box_seal() if you'd like a
reference implementation.

The analogous ​attacks on RS256/HS256 confusion do not apply: If you
attempt to crypto_auth_verify(signature, message, pk) instead of
crypto_sign_verify_detached(signature, message, pk), it will fail in
constant time (i.e. the signature is not long enough).

In fact, in *all* cases the preferred underlying library will fail closed
without leaking useful timing information. Can the same be said of the JOSE
standards?

​
> Failure to check inputs has been the cause of all the major
> vulnerabilities.
>

​No, a badly-written standard that maximizes the joinery between different
cryptography protocols, encourages users to mix-and-match primitives, and
has weird key encapsulation schemes (n.b. AES-GCM does not belong in the
same category as public-key cryptography), while placing all the blame on
libraries and users, and furthermore has not been designed with the
assistance of a professional cryptographer, has been the root cause of all
the major vulnerabilities.

As an industry, we've grown past the point to where we can just blame users
for mistakes enabled by our error-prone cryptographic designs. Has the IETF
lagged behind here?

​
> ​
> This
> ​
> plan adds precisely no additional security ​


​That's an interesting claim, and easily debunked:

By getting rid of RSA PKCS1v1.5 encryption and signing, we eliminate any
chance of Daniel Bleichenbacher's 1998 or 2006 attacks against RSA +
PKCS1v1.5 padding, which increases the security of implementations by a
nonzero amount.

If anyoune would like to argue that PKCS1v1.5 is just fine (insert dog
drinking coffee in a house fire here), be sure to CC some of the TLSWG and
CFRG members; they could use a laugh.

Security Team
Paragon Initiative Enterprises <https://paragonie.com/security>​