[secdir] Secdir last call review of draft-ietf-jmap-blob-15
Shawn Emery via Datatracker <noreply@ietf.org> Mon, 07 November 2022 00:19 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4DC14CF0F; Sun, 6 Nov 2022 16:19:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Shawn Emery via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-jmap-blob.all@ietf.org, jmap@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.20.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166778039050.63276.4467010407995718121@ietfa.amsl.com>
Reply-To: Shawn Emery <shawn.emery@gmail.com>
Date: Sun, 06 Nov 2022 16:19:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/IHOaCgM2t_is3KPofkA36C24Cx4>
Subject: [secdir] Secdir last call review of draft-ietf-jmap-blob-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 07 Nov 2022 00:19:50 -0000
Reviewer: Shawn Emery Review result: Has Nits This proposed standards draft specifies an extension to the JSON Meta Application Protocol (JMAP). Specifically this draft defines an extension for creating, identifying, and retrieving "blobs" of data without the need of utilizing separate roundtrips. The security considerations section does exist and refers to various ways to mitigate against attacks related to unsupported data types, unauthorized access control, blob existence leaks, mismatch between data type and data, and the fragmentation of data to bypass scanner checks. I concur with the set of possible attacks on this extension, though I do have one question on this sentence: The server SHOULD NOT reject data on the grounds that it is not a valid specimen of the stated type. Is there ever a case that one implementation accepts the data that does not match the specified type and then another implementation assumes that the data is that of the specified type? If this is the case then this could lead to vulnerabilities while parsing said data. The security consideration section should also initially state something similar to that of RFC 8621: All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described [below]. General Comments: Thank you for the variety of examples, though it would have been easier to read them if the request and response were in sequence rather than trying to remember which response went to which request or by scrolling up and down a few pages to correlate the two. I'm not for sure I understand the purpose of the Blob/get:properties:digest function. Won't the endpoints be able to do this over the datafield for themselves? Editorial Comments: s/of of/of/ s/supportedDigestAlgorithms/supportedDigestAlgorithms:/ s/in future/in the future/
- [secdir] Secdir last call review of draft-ietf-jm… Shawn Emery via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Bron Gondwana
- Re: [secdir] Secdir last call review of draft-iet… Shawn M Emery