Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 11 August 2020 19:14 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B53A09B8; Tue, 11 Aug 2020 12:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level:
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qQHJO8e2k6XC; Tue, 11 Aug 2020 12:14:43 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 463463A08B9; Tue, 11 Aug 2020 12:14:43 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id z18so12494516wrm.12; Tue, 11 Aug 2020 12:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=ofnvDpdgnaGhZfJ7K89cLO5+xxu1ZiQuyX7+70vOmdAizmJg2OsX9jWCFCCS0z0HLW 5Q5Rk2+TK0Rev3WwAQGLlsk5BmXqqyJPeh0XZzZScOb3lWkCxLQjbBnO/oMh0h7hKsxP zLyNA4sRtLH5OYFEPBEXiwY920zF37WarDBQ+2ctfkc1/Ukv9yULQrAz1/WMV7BePO9+ Uyfj/l8833m+ySGO8KFanCzEDComR6y0TJU8wiFwoW2NTZofmXNQ1xMRj5Xn7nRtFVVy 7P0l3GI1oMmNsLl/kvUXa1Qi2nqFlcpwWf7gXmGRFhSUV3UPkjgoKWNcsVKy1fHQihHE x6jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=uUnceyi6vDMtc84Am7RnEhl/IlTrghm7efoMZtiyCPzZHpCazhlXOkyk5x4f6TlRnC QTymK7uBpSzd0Kxgso9lyubtvaVXj0o3aIfYHwKmgpqCD6xJcziDlrxm2SLB92HoK0bu nqZaFv5+4TbbjpuxOhN1YKaS4xAlA+5k1XxZV3V1ttR+cBtUclUrPCErb104SZ8YVYys 2iuwAM2+BmFxQlJ+1iSjR8Zdpxg/4a9jhCWOHNDOg5CkX3eZ4zOFF24cCoN2yL9wKjFa 3Y962I6VI5xAki3r7bw3/geiG30x2qcnrIjG19qALRb2Y481ctcgHj6WrKCIZIIwNlPm bCfg==
X-Gm-Message-State: AOAM5339OAldFLeBygTmeILZq4pXM5tM+61Hs0gT86MdHfryUE4q9Fik t9t6ImBNq7lyUR7y8RLL+Oo=
X-Google-Smtp-Source: ABdhPJxe/jFFV+V2LN0r9rcZN4+LDD/p8Oi9OEIOPZoHkIWZXoFZWATrbiVEJuEbK7+kYfaSKY/fpA==
X-Received: by 2002:adf:fac8:: with SMTP id a8mr30810494wrs.368.1597173281626; Tue, 11 Aug 2020 12:14:41 -0700 (PDT)
Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id o125sm6998874wma.27.2020.08.11.12.14.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 12:14:41 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Tue, 11 Aug 2020 22:14:39 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Laurence Lundblade <lgl@island-resort.com>, cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org, secdir@ietf.org
Message-ID: <A21FB7FB-664B-4632-BE14-93629BCD01B9@gmail.com>
Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14
References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <B3108FFC-319E-4D8B-8DF4-A866585781DE@island-resort.com> <D3AA9975-187F-485A-A13E-6A878607DBCF@gmail.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org>
In-Reply-To: <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/VNnwJCgEoqu6zoKslQPGAZVKVlE>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 19:14:45 -0000

    > 
    > I understand that, but realistically, without a list of (potential) validity checks in the RFC, there will be wide variance in what is documented by decoders – if any. In fact I checked a few implementations just now, and most of them do not document what validity checks they perform. Those that document something are hard to compare. If you make a canonical list, people would have a starting point.

    To be fair, you probably checked RFC 7049 implementations, and RFC 7049 didn’t have such a requirement (improving the discussion of validity was one of the major work items in 7049bis, see Appendix G.3).

    One point to keep in mind is that, with CBOR, most validity processing happens in the processing of tags, and that is an extension point.  So a list in 7049bis will never be complete.  Even if it only covers base CBOR and the tags registered in 7049/7049bis, a detailed version is likely to be tedious and highly dependent of specific implementation approaches.

    Trying to imagine the outcome of this exercise, my visual image right now is a PICS Proforma, so I think I’ll better stop here...

    Grüße, Carsten

Hi Carsten,

You are addressing this issue from the point of view of a spec writer, I suggest you take the POV of the implementer, the user of a decoder. Those people are not CBOR experts, and when faced with free-form and probably terse documentation of a decoder's validity checking would never know what they need to consider to add as application-level checking.

I realize that tags are an extension point, but if we are to avoid decoding-related vulnerabilities, I suggest you list validity checks for the base CBOR and tags in RFC7049+bis.

Thanks,
	Yaron