[jose] Towards a More Secure JOSE Standard

Paragon Initiative Enterprises Security Team <security@paragonie.com> Wed, 29 March 2017 16:19 UTC

Return-Path: <scott@paragonie.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5F129444 for <jose@ietfa.amsl.com>; Wed, 29 Mar 2017 09:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=0.001] autolearn=ham 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 quIPXbyjpsTO for <jose@ietfa.amsl.com>; Wed, 29 Mar 2017 09:19:55 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 CACBF12943A for <jose@ietf.org>; Wed, 29 Mar 2017 09:19:53 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id t8so13658354otf.3 for <jose@ietf.org>; Wed, 29 Mar 2017 09:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=CPtaEoMlpVUnhDbeUpDLzLFdc47/UBScgKK75BKkGfA=; b=B5UwZAzwJmlgwzdiY3f1TJbis6VyhcIJ2+RRNIoUE6Pwv7Lz+cgxgpVAgiELhtSYM9 TivYL9bnrsyfOkhYmUap16IxTREeOwddkFvl8F0KJJd7nd/UVl2J0U2NB8vOS6sZQh8H dei9XrJxR0TAVXYV7ysPI16StwlgTWKJBkRXrRgetwYk8p4iAJBrsyziIjp3hhoWphb7 3OO4WtLdEXustYgtabZHtISFdpgGsOFtrDIyEgDjQsId75PX6kMr7MJeY+kYX1XmkjQ4 X1BPFHNmhNG5fk3y1VhDh4+z86iDB7dx6zrTHn6Vv+5Y/85hZslp2xbdtGxTfrPlTXQ9 /SAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CPtaEoMlpVUnhDbeUpDLzLFdc47/UBScgKK75BKkGfA=; b=AtbOYo8pfDYGHUoP17XNGJy5SqFneKfxIHTYX+RoA2QsOs1+a9Exd5yQuFn8BVXDhq zJuOggnaf8XGEjBGB/g2ICZ7fc4JWowoNw7AJ9uUXunCEYKKwkJbvHPmFDkh5RltPHSi XDaQPA6RW3GQAP+nfw/yd45g5ZvUBE9edhiZApX6rLaTy1l2LODI49GGb69BB/KBt3n0 cgHflo8/+7HK8K4VI12C/pTWB/XH3y2h27O4Db4LL9YO60Ntyv6biVwffG5itN1ZP6c2 d4hAgTfEDDYXfg96xpTcZZ5M5koI7DFo6K9wWbr0LOWqwuN0MGW5kN8x7EC357tiLCMF WUig==
X-Gm-Message-State: AFeK/H2d8v1s9FXq4Zh1ucpyBAqcNp1UV0kvnXHzeJmS3dzsAhEbRN1WTKi1ntlByX1J+2Ptmsg5gziCG76PrQ==
X-Received: by 10.157.28.142 with SMTP id l14mr641914ota.199.1490804392895; Wed, 29 Mar 2017 09:19:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.46.198 with HTTP; Wed, 29 Mar 2017 09:19:52 -0700 (PDT)
From: Paragon Initiative Enterprises Security Team <security@paragonie.com>
Date: Wed, 29 Mar 2017 12:19:52 -0400
Message-ID: <CAKws9z0UxAFynhW1jf34VARyV82VHVEwhg4E4rcyMMtSGeHj4w@mail.gmail.com>
To: jose@ietf.org
Content-Type: multipart/alternative; boundary=f40304354d8444bf1e054be0f2fc
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Y8gLVAXVPorvF_hnv0L5F4oS8A4>
X-Mailman-Approved-At: Wed, 29 Mar 2017 09:31:52 -0700
Subject: [jose] Towards a More Secure JOSE Standard
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 16:19:58 -0000

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/c88290347c2589b0cd38d8bb6ac27c03,
but I have mirrored them below.

Changes to JOSE that will prevent insecurity
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#deletions>
Deletions
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jws-and-jwe>JWS
and JWE
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#drop-the-alg-header>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
<http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1>;. On a
higher level, this can lead to reasoning by lego
<http://www.cryptofails.com/post/121201011592/reasoning-by-lego-the-wrong-way-to-think-about>
.

For all the reasons outlined here
<https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>
and here
<https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web-tokens>;, the
alg header (and algorithm agility in its entirety) should be considered
harmful.
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jwe>
JWE
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#drop-the-enc-header>Drop
the enc header

For the same reason we're dropping the alg header, we should drop the enc
header.
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#consider-dropping-the-zip-header>Consider
dropping the zip header

As we've seen with CRIME <https://en.wikipedia.org/wiki/CRIME> and BREACH
<http://breachattack.com/>;, as well as this error oracle attack against
iMessage
<https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-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.
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#additions>
Additions
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jws-and-jwe-1>JWS
and JWE
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#new-header-ver-version>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.
<https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#new-header-mode>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 <https://paragonie.com/security>