Re: [jose] Towards a More Secure JOSE Standard

Nathaniel McCallum <npmccallum@redhat.com> Wed, 29 March 2017 19:29 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 D4F2912963F for <jose@ietfa.amsl.com>; Wed, 29 Mar 2017 12:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 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, 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 8NYoe99teCgD for <jose@ietfa.amsl.com>; Wed, 29 Mar 2017 12:29:09 -0700 (PDT)
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (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 4BB9D1200FC for <jose@ietf.org>; Wed, 29 Mar 2017 12:29:09 -0700 (PDT)
Received: by mail-io0-f179.google.com with SMTP id z13so5678986iof.2 for <jose@ietf.org>; Wed, 29 Mar 2017 12:29:09 -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=8CanV+1qI0jwIqQbf6PjVp2/l7OtgZTdFb7YyqrkK7M=; b=rcEdGkMwEJwSHyyte15Zknj/IHsF2LuErS2zP60Izce45ti8VoBqYpqsfWmp3vkDcb HszaHYni/XL8UAHzJLQ+8PMPyRR122ooi8scN5t9smZ0K45i24K5glFDh89r8Cd7A2Gm TkSbYEIgOFlAe1yJAGu5Sd07ZdDJFgGVuZ5OCbkk3U0DOHROiYvKQRZYgOAtxVoYyPpw FZrrmL4fyjopcR9znmkafyUQAaU9psqJsD2X/SzzWFG5cL05nqeu7yJuuOiab1w8fuuV b0kHZoU7yj7HsF2xowCbz4xc5lv/W027y7mWMcgWb2TERVw/aD3zkuzvb5/kFYWjGPgz 4aAQ==
X-Gm-Message-State: AFeK/H2vIl42XZtws7X5xynP0Kw6VVTsfS59mmT0ZJ3feirR7kB15pvyESPpKFqu8Ep2K2+ZfbQ68lkAlTnqAnBz
X-Received: by 10.107.192.193 with SMTP id q184mr2836562iof.110.1490815748512; Wed, 29 Mar 2017 12:29:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.82 with HTTP; Wed, 29 Mar 2017 12:29:08 -0700 (PDT)
In-Reply-To: <CAKws9z1jhYfE4fJBSn9Yp+ETKRgsiH6ZsW5J76AfytWSAY-85w@mail.gmail.com>
References: <CAKws9z0UxAFynhW1jf34VARyV82VHVEwhg4E4rcyMMtSGeHj4w@mail.gmail.com> <FCF428D5-9FF5-460D-8C54-D148177A38F9@mit.edu> <CAKws9z1jhYfE4fJBSn9Yp+ETKRgsiH6ZsW5J76AfytWSAY-85w@mail.gmail.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Wed, 29 Mar 2017 15:29:08 -0400
Message-ID: <CAOASepN8Q5aZEfkc6buoTpBo_Xpoavxt1e5qruX6Cg24K3Ec2g@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/k602LrvKTC9DSM7rx1Lk17JHjdM>
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: Wed, 29 Mar 2017 19:29:12 -0000

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.