Re: [secdir] Secdir last call review of draft-ietf-jmap-sieve-19

[Ken Murchison <[e-mail]>]

Hi Mohit,

Thank you for the review.  Responses below.


On 3/18/24 2:11 AM, Mohit Sethi via Datatracker wrote:
> Reviewer: Mohit Sethi
> Review result: Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These comments
> were written primarily for the benefit of the security area directors. Document
> editors and WG chairs should treat these comments just like any other last-call
> comments.
>
> This document defines an API for managing Sieve scripts on a server using the
> JSON Meta Application Protocol (JMAP). Sieve scripts are used for filtering
> email messages. It defines the following * A new JMAP data type called
> "SieveScript" * Reserves a new URI urn:ietf:params:jmap:sieve for referring to
> sieve script capability supported on the JMAP server * Two new JMAP error
> codes: invalidSieve and sieveIsActive
>
> The document seems ready. It was easy to read and understand. The security
> considerations section simply points to security considerations of RFC 8620 and
> RFC 5228.
>
> One thing that I wondered while reading is how the integrity of the script blob
> is ensured? How does the receiver verify the integrity of the binary script
> content received? I guess JMAP is always expected to use TLS as the underlying
> communication protocol and hence there is integrity during transit. I wonder if
> there are any other means? I briefly read RFC 8620. It seems the blobId is
> somehow derived from the blob content because of the following text: "If
> identical binary content to an existing blob in the account is uploaded, the
> existing blobId MAY be returned." But it is never explained how the blobId is
> generated in the first place. It seems to be some sort of a hash which can
> provide some way of integrity checking of binary data. Anyhow, there is nothing
> to be fixed in this draft. Maybe something to consider for the original JMAP
> RFC 8620.


Its possible that client and servers you do integrity checking per RFC 
9530, but as you suggest, that it something that some be addresses in 
the JMAP core spec.

> One tiny nit:
>
> Link in the the following text appears to be broken: "Script content must first
> be uploaded as per Section 2.2". The xml source looks correct "Script content
> must first be uploaded as per <xref target="content"/>" but the link takes to
> me to the top of the page instead of section 2.2.

I'm guessing that this is an issue with the tooling that we can fix 
during AUTH48.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC