Re: [Last-Call] Secdir last call review of draft-ietf-jmap-blob-15

[Bron Gondwana <brong=40fastmailteam.com@xxxxxxxxxxxxxx>]

On Mon, Nov 7, 2022, at 00:19, Shawn Emery via Datatracker wrote:

Reviewer: Shawn Emery

Review result: Has Nits

Hi Shawn, thanks for your review!

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 type information isn't stored with the blob, so - you only know the type if it's passed.  The idea behind the blob store in JMAP is that it's just octets with no associated meaning.

I would be happy to change this to MUST NOT reject 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].

I will add this.

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.

Unfortunately that's not possible with JMAP, since it's a batch protocol, and the examples are written as batches since that's how they would be used in practice.

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?

The idea is that a client with a partial download of a blob is able to calculate the digest of the section it has, and ask the server to verify that it's not corrupted by calculating a digest over the same range.

Editorial Comments:

s/of of/of/

s/supportedDigestAlgorithms/supportedDigestAlgorithms:/

s/in future/in the future/

I believe the last of those is legitimate usage either with OR without the "the", but I'm happy to add it.

Have made these three edits.

All the changes from your review are in -16.  I have left the content type checking as SHOULD NOT.

Thanks,

Bron.

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

  brong@xxxxxxxxxxxxxxxx

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call