Re: [jose] Towards a More Secure JOSE Standard

Nathaniel McCallum <npmccallum@redhat.com> Fri, 31 March 2017 16:03 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 2B65112968B for <jose@ietfa.amsl.com>; Fri, 31 Mar 2017 09:03:43 -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 vaF2mg7w36ia for <jose@ietfa.amsl.com>; Fri, 31 Mar 2017 09:03:41 -0700 (PDT)
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (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 0CD211242EA for <jose@ietf.org>; Fri, 31 Mar 2017 09:03:41 -0700 (PDT)
Received: by mail-io0-f170.google.com with SMTP id z13so42541705iof.2 for <jose@ietf.org>; Fri, 31 Mar 2017 09:03:41 -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; bh=wwE+zscv2cdPum4qXPYVmOjp7ug4NHdQ3SIcNQuVPmE=; b=fXkNduOKZJYUXrbc6XC8yf+aSKSjD7GJp2fQpUI6nrJuSHsuRgfslvZs7EeNYZ3Ile iOmTHbkJZp1vq4LvTCN5+nJELkPeQ8EzV3FQzRyE53Tvf50DuQLCc8AzECphL+DyJAa0 FKvdFYY/oMK7aWQas5A9NQrScF48VYUWfiqXAQM58RyL+zGAOh8PxM+siHkLJoAAVNWW BEBrf3XUGW5Q46KP+tn84ba9u2y5S4wyQKdmxT8Iue3JydpKAh68ZUcUwef+17Ahh8B3 YqGZhV+dXNQBNI1h4gn97GoN95RjFF0PqkG1MzYlNGAa3C72e9QOx4BUEKhiw/xphrz2 sNUg==
X-Gm-Message-State: AFeK/H1CwAE85yqbUg/F7gObUVLrM8KVHQzDo93535BDTF6Wdetc+Y4SUN1u7d6tIVoFnh/chRem9yCbkA9FhLS1
X-Received: by 10.107.136.41 with SMTP id k41mr4288785iod.160.1490976220044; Fri, 31 Mar 2017 09:03:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.82 with HTTP; Fri, 31 Mar 2017 09:03:39 -0700 (PDT)
In-Reply-To: <CAKws9z3KTNNk-GkgCHeH65dg=cOCuVQexKUdbjbPqYMFm+GB2w@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> <CAOASepNaSLmey8fO0zzH77tfbQpyGadgQPSUjDcxT7LJYezjrA@mail.gmail.com> <CAKws9z3KTNNk-GkgCHeH65dg=cOCuVQexKUdbjbPqYMFm+GB2w@mail.gmail.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Fri, 31 Mar 2017 12:03:39 -0400
Message-ID: <CAOASepPO7dnC5smQ4+Z4p6Z9iVG3y8X7D9M+y1kfECN48gzDRQ@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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/u2aIL0af-1q1ze_VgHxFFpqI8f8>
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 16:03:43 -0000

These are both applicable here:
    http://rationalwiki.org/wiki/False_dilemma
    https://xkcd.com/927/

It is very reasonable to tell people to ensure that their crypto
library is written by a security professional who understands
cryptography and ensures that inputs are validated.

Is is also sensible to write a follow-up RFC detailing security
considerations for implementers. Once done, you can tell people to
only use JOSE implementations that have performed conformity audits
against the new RFC.

Further, you can make sensible proposals to downgrade the IANA
recommendation level of algorithms subject to various attacks. This
can be done without a new RFC.

These approaches will have a far broader impact on the cryptography
ecosystem than proposing a new standard.

On Fri, Mar 31, 2017 at 11:49 AM, Paragon Initiative Enterprises
Security Team <security@paragonie.com> wrote:
>
> On Fri, Mar 31, 2017 at 11:46 AM, Nathaniel McCallum <npmccallum@redhat.com>
> wrote:
>>
>> On Thu, Mar 30, 2017 at 1:52 PM, Paragon Initiative Enterprises
>> Security Team <security@paragonie.com> wrote:
>
>
> (SNIP)
>>
>>
>>
>> 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.
>
>
> The alternative is to tell people don't use JOSE, it's a bad standard and
> design a superior alternative to recommend instead. One that has actually
> been vetted by cryptography experts.
>
> Given only those two options, which would you rather see?
>
> Security Team
> Paragon Initiative Enterprises
>