Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Richard Barnes <rlb@ipv.sx> Mon, 14 December 2015 16:22 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256E1A8BAF for <jose@ietfa.amsl.com>; Mon, 14 Dec 2015 08:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 AgGoXznMpVBJ for <jose@ietfa.amsl.com>; Mon, 14 Dec 2015 08:22:37 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 75C5F1A8A43 for <jose@ietf.org>; Mon, 14 Dec 2015 08:22:35 -0800 (PST)
Received: by vkha189 with SMTP id a189so156621640vkh.2 for <jose@ietf.org>; Mon, 14 Dec 2015 08:22:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kp13oNTofnWiApOHn7t8u9mL/4MzrnJPOCMQ+VE99Pc=; b=B6bGy6DxVrSIY0HUD8+K3N0ES4sHhwm23Y0eJjmWabG9/0aArf8FKJef7TXJ7CuzUC lBaf4TRppgTpTWLO9lrXGnqLrp5AzrSYSGbXY1TYDpl2G+VZtG4eiD2Kkx2py/p/SdDh TgdTuBCE5yNpg8QLd7U5Nu9iieog3jaxO+O/6013fT+5lnEziJwF2in2kB2MCaGJIsm4 ljJKjLED3d/DQLZpgnDqQ5gohvT+Oo5KQkCPMP0Mrg81I4etws2M82HXF1HZs+Iml5gD +n6qdG95RKHugnzNx3CrOtkBdYRnAX11NVbYHT9LNmh170OeewPqyasXjqbfY6qxvoC9 FK9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kp13oNTofnWiApOHn7t8u9mL/4MzrnJPOCMQ+VE99Pc=; b=CUGC097s3RBRtZI3EpE4LRh9Lj2UiHV7l+csiWougeXBRbmF/1xdle8+KrB25IntZm 3+GgDDUHJWPI5V2I8sXBW7NhV6P7nI9rzb08WQpQl/CtdR6JBS6fPhW8rqRaCx7jGhnO /gjoO2glEPCOhBeP0gTem1tySE4qWLChrL+G5nZVGsv3ovWiDilctevKjPqDRf+ItwZR IOM9xqkE0h8RPvR6GbswldInwBHZfaiRz7ePvVX6dlKIzPPrv8mfRmAVL06upELvEvo9 zbkvgBUwZV5u3JoihfFDse4h4Aao0P3R7cHmwNOSoPGdIDPwmH/6QIhp+jGZpGydAI6s hcvw==
X-Gm-Message-State: ALoCoQkutXKVwhK5JOqJc6M4Bm5c0VMVAnFMZDBhShaDgpVVX03In/4caO63mGZf+AKyVw/8Xy/vipwn2LlOkmG4GH0ZggI5Hg==
MIME-Version: 1.0
X-Received: by 10.31.15.4 with SMTP id 4mr22804899vkp.10.1450110154600; Mon, 14 Dec 2015 08:22:34 -0800 (PST)
Received: by 10.31.11.81 with HTTP; Mon, 14 Dec 2015 08:22:34 -0800 (PST)
In-Reply-To: <566EEA3E.8070302@nostrum.com>
References: <5661E491.9050007@nostrum.com> <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com> <566DDF01.1020806@nostrum.com> <BY2PR03MB442BCE6CA07CC6EA7A86684F5ED0@BY2PR03MB442.namprd03.prod.outlook.com> <566EEA3E.8070302@nostrum.com>
Date: Mon, 14 Dec 2015 11:22:34 -0500
Message-ID: <CAL02cgSfUWmWamr7mwWeC8S6R8B9r6rinvn-2AYxZyvOiJJHLQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/CuhaWqkdk4OJxDrgm4KsnBekjds>
Cc: Mike Jones <Michael.Jones@microsoft.com>, "draft-ietf-jose-jws-signing-input-options@ietf.org" <draft-ietf-jose-jws-signing-input-options@ietf.org>, General Area Review Team <gen-art@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 14 Dec 2015 16:22:39 -0000

Hey Mike,

tl;dr: I agree "crit" needs to be required.

If I understand you correctly, you're observing that if the receiving
implementation supports "b64":false, then there's no need for
"crit":["b64"], so it's proper for the JWS to still verify.  That
seems pretty tautological, given that the whole point of "crit" is to
address implementations that *don't* support "b64".

This seems to hearken back to several debates we had in the initial
JOSE round, where if you had some assumption outside the JOSE spec,
then everything was OK.  As the SEC ADs pushed back at the time, so
I'm pushing back now: The JOSE specs need to be themsleves internally
consistent.  Yes, if you use "b64" without "crit" in a closed
community where everyone supports "b64", then you'll be OK.  But
that's not an interoperable behavior.  If one of these JWSs ever leaks
-- by error or malice -- then you're back in the case where you can
have non-supporting recipients.

You could argue that the impact of interop failure isn't terrible
here, because it fails closed -- it's unlikely that a signature over
$CONTENT will verify with regard to base64($CONTENT).  I don't have a
concrete attack scenario, but this seems to invite confused deputy
problems of the same sort that arise in XML-DSIG.  Let's not go there.

--Richard


On Mon, Dec 14, 2015 at 11:11 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
> Mike -
>
> No, this still doesn't explain why crit is not sufficient.
>
> You are making a bare assertion that using crit doesn't achieve a). I think
> it does. Please explain (in the draft) why it doesn't.
>
> You are making me guess, but I think you are only trying to avoid having to
> include the few extra bits in the message. If you've _done_ the work of
> ensuring all the applications understand using b64 through some out-of-band
> magic, then including crit will just work. Are you pushing back on anything
> _but_ the packet-bloat in this case?
>
> If you _haven't_ done this out-of-band work, and you send to a receiver that
> understands the extension, then a) is achieved. If you send to a receiver
> that doesn't understand, things _should_ fail - arguably this also achieving
> a), though I suspect you are wincing at perhaps not having a clear path to
> recovery in this case?
>
> I really think this boils down to you not wanting to pay the extra few bits
> in the packet to say "crit".
> if that's not the case, please explain (and again, this needs to be in the
> draft, not just an email thread).
>
> RjS
>
>
>
>
> On 12/13/15 10:04 PM, Mike Jones wrote:
>>
>> Hi Robert,
>>
>> You asked "_WHY_ is crit not sufficient? I think that's the thing that's
>> missing as motivation."
>>
>> There are two goals we're discussing, which are related:
>> (a) Having an application that uses "b64":false work.
>> (b) Having an application that receives a JWT with "b64":false not
>> misinterpret the payload content.
>>
>> Including "crit":["b64"] would be sufficient to achieve (b), as it would
>> cause the JWS to be rejected by implementations not supporting "b64".  But
>> it does not achieve (a), since the JWS would be rejected.
>>
>> In contrast, using an implementation that understands "b64" achieves both
>> (a) and (b) without needing to include "crit".  That's why it's not
>> required.
>>
>> Does that make sense now?
>>
>>                                 Best wishes,
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Sunday, December 13, 2015 1:11 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>om>; General Area Review Team
>> <gen-art@ietf.org>rg>; ietf@ietf.org; jose@ietf.org;
>> draft-ietf-jose-jws-signing-input-options@ietf.org
>> Subject: Re: Gen-Art LC review:
>> draft-ietf-jose-jws-signing-input-options-06
>>
>> Cutting away a bit to focus on the question:
>>
>> On 12/12/15 8:32 PM, Mike Jones wrote:
>>>
>>> Hi Robert.  Thanks for the useful review.  Replies are inline below...
>>>
>>>> -----Original Message-----
>>
>> <snip/>
>>>>
>>>>
>>>> I would have been much more comfortable with a consensus to require
>>>> 'crit'.
>>>> (Count me in the rough if this proceeds with crit being optional).
>>>>
>>>> I assume there is a strong reason to allow for option 1. Please add
>>>> the motivation for it to the draft, and consider adding a SHOULD use
>>>> 'crit'
>>>> requirement if option 1 remains.
>>>
>>> It's a reasonable request to have the draft say why "crit" isn't
>>> required.  My working draft adds the following new paragraph at the end of
>>> the security considerations section to do this.  Unless I hear objections,
>>> I'll plan on publishing an updated draft with the paragraph shortly.
>>>
>>> "Note that methods 2 and 3 are sufficient to cause JWSs using this
>>> extension to be rejected by implementations not supporting this extension
>>> but they are not sufficient to enable JWSs using this extension to be
>>> successfully used by applications.
>>
>> The conclusion you draw here is not at all obvious.
>> _WHY_ is crit not sufficient? I think that's the thing that's missing as
>> motivation.
>>
>>>    Thus, method 1 - requiring support for this extension - is the
>>> preferred approach and the only means for this extension to be practically
>>> useful to applications. Method 2 - requiring the use of <spanx
>>> style="verb">crit</spanx> - while theoretically useful to ensure that
>>> confusion between encoded and unencoded payloads cannot occur, is not
>>> particularly useful in practice, since method 1 is still required for the
>>> extension to be usable. When method 1 is employed, method 2 doesn't add any
>>> value and since it increases the size of the JWS, its use is not required by
>>> this specification."
>>>
>>>> Nits/editorial comments:
>>>>
>>>> In the security considerations, the last sentence of the first
>>>> paragraph needs to be simplified. I suggest replacing it with:
>>>>
>>>> "It then becomes the responsibility of the application to ensure that
>>>> payloads only contain characters that will not cause parsing problems
>>>> for the serialization used, as described in Section 5. The
>>>> application also incurs the responsibility to ensure that the payload
>>>> will not be modified during retransmission.
>>>
>>> I have simplified this in the manner that you suggested.
>>>
>>>                                 Thanks again,
>>>                                 -- Mike
>
>