Re: [jose] #23: Make crypto independent of binary encoding (base64)

Naveen Agarwal <naa@google.com> Thu, 13 June 2013 00:53 UTC

Return-Path: <naa@google.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 39F9121E805A for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 17:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaaLfv5wNjzD for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 17:53:27 -0700 (PDT)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id A2CA621E8088 for <jose@ietf.org>; Wed, 12 Jun 2013 17:53:26 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id 2so6138762qea.35 for <jose@ietf.org>; Wed, 12 Jun 2013 17:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=162Q/Cqr3fgnu3LaHqIUsUHymuuDZHj/oIPETaL5zJQ=; b=QYeM8oapwkwusEyFM+Mosu8yeJ6pMURVfUz8dJA9UOhgYgYbj154i7Epc3jFajvx6s BHfvBbm4PkB42Td3X/Uj2gtdMnem/sh2pcTVmf1crHdfU3aBV7WNa/nkSBZ7O8IbjD/l AzBaTu2S6aKCVasZCQK8V82Bn0MBqVvTcVTr70AwlKbTqC6CJBHjQztqpHI3bQoEkZRP JRXY+k9dHC7Y5BgZWyuGUbPyeBFRK88t0ln+cwyjAhJC9pwBPzwLhmO2x6tuep0c4gld PIpKM+VEhrJW7hlrQ0d1S1MzLvTau/jduopzhBIud4IV5spugjOAq8T3z5thSYUb+4Sk iHdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=162Q/Cqr3fgnu3LaHqIUsUHymuuDZHj/oIPETaL5zJQ=; b=I/AEjcLT3NBHmrMXDdHeyq4P+Eh7KOnoOBl4lGFJrdPbdqAeMtdA5S8KYXoA2Cl5XN X1hAblIMJd4jcJcbdeR2Ha0DcIMiFx1s80n41e18PRDbOzII2QFxN5VoiDOt/7IMzmEE Og1ogg4/7EZyz5cixb7NoqIM1v1xVLy25WMBe9T2SzgM3QteYr0WZ2LUx+JtnSYwCizA 8xKhKMaVOwxma/ovS+CFJTY16Ml6fGgcGkaWn8OcKZr4W4xuDsWErpO3u/hqIign27kA PgXrm4uYyWeiXqrtjPluYCs/CoH5//5Q3aYTCQ8D4dFYaVs8uSouz+nF+7BRRO5fcJ91 hw4w==
X-Received: by 10.49.35.132 with SMTP id h4mr27460510qej.29.1371084806029; Wed, 12 Jun 2013 17:53:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.154.69 with HTTP; Wed, 12 Jun 2013 17:53:05 -0700 (PDT)
In-Reply-To: <CAL02cgSpYtAVVNe7AOiNhnBUqP-=CWaXw7NH2XwUu6eXgfZJ+w@mail.gmail.com>
References: <049.69ffc5ebf959c6eac7990651822fadf9@trac.tools.ietf.org> <064.e396e921644745f7bd339ad363a7d7f7@trac.tools.ietf.org> <BF7E36B9C495A6468E8EC573603ED94115283F43@xmb-aln-x11.cisco.com> <CAL02cgSpYtAVVNe7AOiNhnBUqP-=CWaXw7NH2XwUu6eXgfZJ+w@mail.gmail.com>
From: Naveen Agarwal <naa@google.com>
Date: Wed, 12 Jun 2013 17:53:05 -0700
Message-ID: <CAOKiTbtHGWFA4sdgNWG+KY483gkz5DbxC3jWhTVsn9fNzOb2_w@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="047d7b6778a6d21c4204defe8ec6"
X-Gm-Message-State: ALoCoQlRS4q6tpB2EJPpTX0xlEXqV0Et9yWv2zPaTiOUNJONVh3HG8FLMnUxILemElLNs8u3nXT6PyePfGLZPtGoT3q9iZNoA57uCapJbJfB2Gs8FKxWoxIvoq1klKkF1NA5u8f8eDoxTYk6ZT2qmSSmHOmWPdtDBRCDTpuJp8MyYWSxmYS1iFGwp7vz0cRX880prp3lsrMl
Cc: "<draft-ietf-jose-json-web-encryption@tools.ietf.org>" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "<michael.jones@microsoft.com>" <michael.jones@microsoft.com>, jose issue tracker <trac+jose@trac.tools.ietf.org>, "<jose@ietf.org>" <jose@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Jun 2013 00:53:32 -0000

But I think we're literally talking about something like a 5-line patch.


Unfortunately there are lot of clients apps that are using jwt and
modifying those apps is not going to be easy.
Whether it is a one line or two line change, it doesn't matter. Breaking
change for something that is working well is bad idea (unless it is for
security reason).


Naveen





On Wed, Jun 12, 2013 at 1:23 PM, Richard Barnes <rlb@ipv.sx> wrote:

> <impartial-analysis>
> So just to be clear on the trade-off the WG has to make:
>
> On the one hand: Breaking every existing JWT implementation in the world
> On the other hand: Eternally binding ourselves to base64 encoding, even if
> binary-safe encodings become available (CBOR, MsgPack, etc.)
> </impartial-analysis >
>
> <personal-opinion>
> I have some sympathy with JWT implementors.  It sucks to have to refactor
> code.  But I think we're literally talking about something like a 5-line
> patch.  And early JWT implementors knew or should have known (to use a DC
> phrase) that they were dealing with a draft spec.  As the W3C editor's
> draft template says, in big bold red print, "Implementors who are not
> taking part in the discussions are likely to find the specification
> changing out from under them in incompatible ways."
>
> As PHB pointed out in the other thread, it would be nice to use JWS and
> JWE in place of CMS one day, without the base64 hit.  We should incur the
> implementation pain now, and get the design right for the long run.  Base64
> is a hack around JSON; we should build the system so that when we no longer
> need that hack, it can go away.
> </personal-opinion>
>
> --Richard
>
>
>
>
> On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2) <
> mamille2@cisco.com> wrote:
>
>> I did at first find it curious why the cryptographic operations were over
>> the base64url-enccoded values, but I was also very focused on JWE, where I
>> think the field separation problem is less of an issue (at least now).  For
>> JWS, this would certainly cause problems without some manner of unambiguous
>> field parameterization.
>>
>> I will note that unescaped NULL is not valid in JSON, so it could be used
>> as a separator between the encoded header and the payload.  I do find it
>> interesting if JOSE could more easily and efficiently support other
>> encodings.  However, I think that while this is an interesting thought
>> experiment, it seems we're too far down the path to seriously consider it
>> unless the current state were shown to be horribly broken.
>>
>>
>> - m&m
>>
>> Matt Miller < mamille2@cisco.com >
>> Cisco Systems, Inc.
>>
>> On Jun 11, 2013, at 6:01 PM, jose issue tracker <
>> trac+jose@trac.tools.ietf.org> wrote:
>>
>> > #23: Make crypto independent of binary encoding (base64)
>> >
>> >
>> > Comment (by michael.jones@microsoft.com):
>> >
>> > For both serializations, you already need the base64url encoded versions
>> > of the JWS Header and the JWS Payload to preserve them in transmission,
>> so
>> > computing them isn't an extra burden.  In the JWS Compact Serialization,
>> > you already need the concatenation of the Encoded JWS Header, a period
>> > character, and the Encoded JWS Payload, so computing that concatenation
>> > isn't an extra burden.  Given you already have that quantity, computing
>> > the signature over it is the easiest thing for developers to do, and
>> it's
>> > been shown to work well in practice.  There's no compelling reason to
>> make
>> > this change.
>> >
>> > Even for the JSON Serialization, the only "extra" step that's required
>> to
>> > compute the signature is the concatenation with the period character -
>> to
>> > prevent shifting of data from one field to the other, as described by
>> Jim
>> > Schaad in the e-mail thread.  So this step isn't actually "extra" at
>> all -
>> > it's necessary.  It's also highly advantageous to use exactly the same
>> > computation for both serializations, which is currently the case.
>> >
>> > Since there is no compelling reason to make this change, and since
>> making
>> > it could enable the "shifting" problem identified by Jim, it should not
>> be
>> > made.
>> >
>> > --
>> >
>> -------------------------+-------------------------------------------------
>> > Reporter:  rlb@ipv.sx   |       Owner:  draft-ietf-jose-json-web-
>> >     Type:  defect       |  encryption@tools.ietf.org
>> > Priority:  major        |      Status:  new
>> > Component:  json-web-    |   Milestone:
>> >  encryption             |     Version:
>> > Severity:  -            |  Resolution:
>> > Keywords:               |
>> >
>> -------------------------+-------------------------------------------------
>> >
>> > Ticket URL: <
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
>> > jose <http://tools.ietf.org/jose/>
>> >
>> > _______________________________________________
>> > jose mailing list
>> > jose@ietf.org
>> > https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>