Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

Jeffrey Yasskin <jyasskin@google.com> Wed, 24 July 2019 22:18 UTC

Return-Path: <jyasskin@google.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520AD1202C5 for <cbor@ietfa.amsl.com>; Wed, 24 Jul 2019 15:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Jw-P3x6fMtqC for <cbor@ietfa.amsl.com>; Wed, 24 Jul 2019 15:18:01 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 845431202C3 for <cbor@ietf.org>; Wed, 24 Jul 2019 15:18:01 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id h28so32999329lfj.5 for <cbor@ietf.org>; Wed, 24 Jul 2019 15:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3/u4Rh35h9JVpyAsY5GAykiANOvq2V+HMgcDR4ciX8A=; b=edX8FqFJyvAaPYvIUKIltDIVn1uPrRsTyvAqAyJWmCKmlKBvzNrAa0XwjJ7bItv4rW JFkE5/P1DwfROs0CeEIVtTkkqgJDLFVbsOWEA60jR5zCMxss6ojQyE/JYIHLcoA10VPx IVHnUIhh4kZZvmHuWRvVN+u+XLtjpmqM2YNT5f/Pa/+n9RUI1o7UDVm99YjXZnvBfI27 ikZgsH5cDc/rqmgYkashmANjzpBxE9SWx08UHA4n5RV6876pZWvUzyCKl/tT3t5yfNXg JcZelkE/sxk9DiBnFuRb7nljDYgFPVOUo8ePMo617GXY5csxzaw0caU6NI5PgIGTBsak OMtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/u4Rh35h9JVpyAsY5GAykiANOvq2V+HMgcDR4ciX8A=; b=lLSjW4y6d9GxMEBlwQiwmc6Ufc3tR8qKqpAzPMzrrUnlOnMEig7dQk8N45N9tF6n7s rDSEfCDMcz2QXUThWcUmJiFTsV21E69o+puRbQCqH16KWe/lNQD2fheLIGfwQOST/fp3 R6Wiz7FiSFdWhpWBiBJnRTqbaxmxlG1zjf2QHSQIz5GIFsiZOhoNytMHse9Jx8+cvkUW SJ1IVMTOYktaCA84A92mvPg0UXz6xUUz9dadwgE247Ka4vDOZXLrrbm8/U9t89FKrQrf bD/lezaffrJ5uRQr+LIkhLEdHjXsP5lqja+SwLCw/rHwZsPDpBaV+RH7c+Y0fMA31YDT HACA==
X-Gm-Message-State: APjAAAVl9UjFittGWhUyDeOaQk0SiZHGFp1Uf2MA1GtdR14Fa5iV7FD6 yu+qKr6aQ+85wP8jDPWR7Ah9GiQ3c0myB1cFTxog/CdLuwc=
X-Google-Smtp-Source: APXvYqxI32MesqzOedfFBnUwt3zYvWHd2JHWi0A/ZzJ/7R3nHvn/LdW+69zTNhR2eDidgvDQ8X06AUWnx8/3EJQznW0=
X-Received: by 2002:a19:750b:: with SMTP id y11mr3742741lfe.16.1564006679196; Wed, 24 Jul 2019 15:17:59 -0700 (PDT)
MIME-Version: 1.0
References: <CANh-dXkkSJUOcHcBj1JRO20ULFVNNbu1GQU-j7bR7N-FCTt3HA@mail.gmail.com> <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org>
In-Reply-To: <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org>
From: Jeffrey Yasskin <jyasskin@google.com>
Date: Wed, 24 Jul 2019 18:17:46 -0400
Message-ID: <CANh-dXm0TLShk_9DT9fKq0CR4yJMr6=zntWL8fW2tB99o0Et3Q@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008a8dd8058e74aee0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/txIB1H327jFVGGXEMU40HOnnszs>
Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 22:18:04 -0000

On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <cabo@tzi.org>; wrote:

> To make sure that we don’t create a trap for generations to fall into, a
> paragraph could be added to the security considerations.
>

That sounds like a good idea.

Jeffrey

>
> Generally speaking, an implementation that wants to perform operations on
> input data will need to validate that to be appropriate for that
> beforehand.  The potential trap here might be that a Uint8ClampedArray
> might feel a lot more like a Uint8Array than other types do to each other
> so the validator would be misled.  So don’t do that…
>
> Grüße, Carsten
>
>
> > On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=
> 40google.com@dmarc.ietf.org>; wrote:
> >
> > In https://github.com/cbor-wg/array-tags/issues/6 I complained that
> > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is
> > a property of further processing rather than the data encoded in CBOR.
> > I worried that we might introduce security issues by allowing a
> > potentially-malicious sender to decide how the recipient processes the
> > received data.
> >
> > More abstractly, I believe this is the only tag in the document that
> > extends the CBOR generic data model.
> >
> > I don't think the current text adequately describes when a recipient
> > should create a Uint8ClampedArray from potentially-untrusted input
> > data. But I 1) didn't object during the last call and 2) don't think
> > this is a big enough issue to try to hold up the process if other
> > folks think it's fine.
> >
> > So, how do other folks feel about the marker for clamped uint8 arrays?
> >
> > Thanks,
> > Jeffrey
> >
> > _______________________________________________
> > CBOR mailing list
> > CBOR@ietf.org
> > https://www.ietf.org/mailman/listinfo/cbor
> >
>
>