Re: [jose] Towards a More Secure JOSE Standard

Nathaniel McCallum <npmccallum@redhat.com> Fri, 31 March 2017 15:46 UTC

Return-Path: <nmccallu@redhat.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 568461294E1 for <jose@ietfa.amsl.com>; Fri, 31 Mar 2017 08:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 258D44p8_r0T for <jose@ietfa.amsl.com>; Fri, 31 Mar 2017 08:46:09 -0700 (PDT)
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (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 DCF281294DF for <jose@ietf.org>; Fri, 31 Mar 2017 08:46:08 -0700 (PDT)
Received: by mail-io0-f174.google.com with SMTP id z13so42209939iof.2 for <jose@ietf.org>; Fri, 31 Mar 2017 08:46:08 -0700 (PDT)
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:content-transfer-encoding; bh=lMbkzUGukFDQxfkYtJdHs322Rd8DxWg75IC9SiEpgG8=; b=eiSLTYbArJtiZbgiGqDBkJ7RT+wnXpCOtbGnj/FhHGEOYurnWTWaNqFYHuvWe+gf1C iIqZRK56ZUp4wlsD+YaMxo3IrxOoDyRZmFoMWp3VcvhzgW9r8zMT/CB1f8HebsQiuHId wE6lpQwSfNG5I9coZBnaYnodbdj4tnRQ0UcPaZZ5csunv6EEq+bbzH8jXVxCP9u+p2Ee OJw0ZiOHJVbE+eEqt/G2JNVVdZ0SL8k+/Ly8dolns/7/NT/eNP28olZRkalByw+wCqAs 3jkYceXxBfSp4IAypHGk5iNlgr/IaeuFjKSj6jQDttFk9tyDkQQIg3yg0b5evSHJ2nSk A2ig==
X-Gm-Message-State: AFeK/H0NH6gWQ/W/OHLzmJ9YdTgP8nlnu5yhJzQOyEniiuQ+pMkTfXdhtEZGFNxrETbpmW1bYgbNkhc9cIN8u73x
X-Received: by 10.107.205.197 with SMTP id d188mr3684186iog.206.1490975167998; Fri, 31 Mar 2017 08:46:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.82 with HTTP; Fri, 31 Mar 2017 08:46:07 -0700 (PDT)
In-Reply-To: <CAKws9z1_H0+YXa-DLPEKKnTdZYQU7U4bvB9iRcDoGiLhcas+wA@mail.gmail.com>
References: <CAKws9z0UxAFynhW1jf34VARyV82VHVEwhg4E4rcyMMtSGeHj4w@mail.gmail.com> <FCF428D5-9FF5-460D-8C54-D148177A38F9@mit.edu> <CAKws9z1jhYfE4fJBSn9Yp+ETKRgsiH6ZsW5J76AfytWSAY-85w@mail.gmail.com> <CAOASepN8Q5aZEfkc6buoTpBo_Xpoavxt1e5qruX6Cg24K3Ec2g@mail.gmail.com> <CAKws9z1_H0+YXa-DLPEKKnTdZYQU7U4bvB9iRcDoGiLhcas+wA@mail.gmail.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Fri, 31 Mar 2017 11:46:07 -0400
Message-ID: <CAOASepNaSLmey8fO0zzH77tfbQpyGadgQPSUjDcxT7LJYezjrA@mail.gmail.com>
To: Paragon Initiative Enterprises Security Team <security@paragonie.com>
Cc: Justin Richer <jricher@mit.edu>, jose@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/xhyLkI5ryYNevo-T8EFcFXz7M80>
Subject: Re: [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: Fri, 31 Mar 2017 15:46:12 -0000

On Thu, Mar 30, 2017 at 1:52 PM, Paragon Initiative Enterprises
Security Team <security@paragonie.com> wrote:
>
>
> On Wed, Mar 29, 2017 at 3:29 PM, Nathaniel McCallum <npmccallum@redhat.com>
> wrote:
>>
>> On Wed, Mar 29, 2017 at 2:36 PM, Paragon Initiative Enterprises
>> Security Team <security@paragonie.com> wrote:
>> > On Wed, Mar 29, 2017 at 2:22 PM, Justin Richer <jricher@mit.edu> 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
>> >> <security@paragonie.com> 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/c88290347c2589b0cd38d8bb6ac27c03,
>> >> 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
>> >> jose@ietf.org
>> >> 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?

It can, yes, be said of the many implementations of the JOSE standards
that were not affected by RS256/HS256 confusion.

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

Implementations that check the requested algorithm against the key
type and allowed key algorithms are not vulnerable. Hence, the root
cause is a failure to verify inputs.

Yes, it would be nice if the standard was less fragile in this area.
But you're asking for a major change to an existing standard after it
is published and many interoperable implementations exist. You have to
realize this is a (very) hard sell.

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

(versus other plans with lower costs)

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

Make a proposal to retire or downgrade RSA PKCS1v1.5 encryption and
signing. I'll support it.

Make the same proposal to retire zip. I'll support it.

These are both very achievable proposals that will significantly
reduce our attack surface.