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

Bron Gondwana <brong@fastmailteam.com> Mon, 18 March 2024 11:25 UTC

Return-Path: <brong@fastmailteam.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 F3671C151990; Mon, 18 Mar 2024 04:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="jX7leJpY"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Ejlpoeaz"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMTojCrEdbwf; Mon, 18 Mar 2024 04:25:07 -0700 (PDT)
Received: from wfout2-smtp.messagingengine.com (wfout2-smtp.messagingengine.com [64.147.123.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B63C151061; Mon, 18 Mar 2024 04:25:01 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id D81B71C00086; Mon, 18 Mar 2024 07:24:51 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Mon, 18 Mar 2024 07:24:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1710761091; x=1710847491; bh=sU+OHMP7nEIvhvZRbGJupfVZ00klqqdPzSEld5xAHVo=; b= jX7leJpY+D2VtgLIU9Q68gUs2PcNS/eFCfpYXnKxJlXv3M9IQ/p2BVAdUZhzWNM/ Yh2BZGdV84SaqLlEb0o36DG0CU6weg+YUIi78zWqNFE+9E1q2RzvnQBs6rnTLP7V oELkbGmdi1ZOkZ8jNnzCT/GL0L66n6wscIx1sa/JVKHncI271XRJ8WdoJYrnEZTn 8G2dNLHs5hAkJy+zrL6OewVFpp3nTSYEy8AecAtTxai80DISFP7oNB0kDPMl9nvD W5jpf1Y7tuQu7bo7xFrGS4wTmd7JIKzASSAq88iAB5b4RfyG9GeOkLeDbI1CPZwx lSIYj0yE0ZD11vl6yegJSA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1710761091; x=1710847491; bh=sU+OHMP7nEIvhvZRbGJupfVZ00kl qqdPzSEld5xAHVo=; b=Ejlpoeaz1I3anTuWza+GEHzojGnLnPShorHFnORA3qxs IavYYFDyJ7xGNti6W9Ew8fFH1P+9BMcQHCSyK0CHMNJmSaZXjgNbuOzF4f2xu7ot pzveuy/L20cirrnZzJ2W8V7Ddo4s1/JJ3TEHHsuVKvrTnDh8LZ3a4HmWN0KHaZ2C TUVpHkg93LwSMApwSHsfBMK07+n6n9ZwoGZGDp/UCIbnZ0iRABw4uvsUkRlJJHAn 9coNzogqqgkW/JVWL/yjYF6PmZUEomtol+0/QiC32nee89ZITfgzehQQ0puCZ08p nSpBEsKKoE2a32zqBZfN4/LRRVHP6PAtyBQWmLzVAw==
X-ME-Sender: <xms:gyT4ZeQATQ104Ns36lPF__V8jh4hyk3yGLzY4PIg2WoLfe7y7OEPIw> <xme:gyT4ZTxVvKpZk0Q9er2cUup2xUDUAN5rkx4QN_z2XuoDI6CCSi0pHFVS9qb59lTco kGwrxNm7_U>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkeejgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepfedvjeegfefhfedtgffgjedvheeigefhfeduvefhgedt udfgueeflefhlefhfeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:gyT4Zb2KdHnCwDvAqMv0lzSP2qGSangqisaJVz1Ml36ivN08nr6qQg> <xmx:gyT4ZaBMZHx_cOgOotI60i3zTYH2qbB4IIOnEWYaXDZWo5ObAgM_-A> <xmx:gyT4ZXgkULMjcUJlc9nUuLtbx6tO69sE7EsPmHC0rLpVUkcHEWH_lw> <xmx:gyT4ZWrzaYlR6LSgbrNvvhwuBnpQ3sCv2GHODQJ6ld3ZlHU-D5ptxA> <xmx:gyT4ZXeNYnl4q3Pdis2p--1L4SZ9w7d-Yx0eY1J_aJatvkqS3WrIVYfSDeE>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0AF812D4007D; Mon, 18 Mar 2024 07:24:51 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-303-g43be7e9a62-fm-20240315.002-g43be7e9a
MIME-Version: 1.0
Message-Id: <12f5d211-3b84-4f12-be3c-a5c15c720af0@app.fastmail.com>
In-Reply-To: <171074230051.11621.14080582299477917640@ietfa.amsl.com>
References: <171074230051.11621.14080582299477917640@ietfa.amsl.com>
Date: Mon, 18 Mar 2024 21:24:31 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: Mohit Sethi <mohit@iki.fi>, secdir@ietf.org
Cc: draft-ietf-jmap-sieve.all@ietf.org, jmap@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="13fb06c63f5f4b0fb295417d0bfb93e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/03bR4VwLXpuJVPp2-IEOVzEfSrM>
Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-sieve-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 18 Mar 2024 11:25:12 -0000

On Mon, Mar 18, 2024, at 16:11, Mohit Sethi via Datatracker wrote:
> 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'm not sure the threat model you're worried about here.

The server gives a blobId for uploaded content and you use the ID.  The server says that this blobId will give the same content if used later.

Either the server is trustworthy and it acts on the same content, or the server isn't trustworthy and ... then what's the difference?  It could substitute anything no matter whether the data is uploaded concurrently or separately.

Bron.


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com