IETF Logo Mail Archive

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

Mohit Sethi <mohit@iki.fi> Mon, 18 March 2024 15:02 UTC

Return-Path: <mohit@iki.fi>
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 59E10C180B79; Mon, 18 Mar 2024 08:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=iki.fi
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 amaPbLDB5Yvv; Mon, 18 Mar 2024 08:02:50 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 5CADAC180B78; Mon, 18 Mar 2024 08:02:48 -0700 (PDT)
Received: from [192.168.58.41] (85-76-97-51-nat.elisa-mobile.fi [85.76.97.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: mohit) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4Tyyl70cGmz49Q4l; Mon, 18 Mar 2024 17:02:42 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1710774166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vsfsoefn/iO/rlRFhdGx8bE9Eu4elkiQlMO1gEJIgAg=; b=rSiWvL99SPqA+ylYuLpxaAtf9XqRDsfv2yjPr0ZfZKoKkAynNTmooo2GGikghTSZcdYdpj HvCUx4TEhX4869zDELuRIeYfhR1lGljr6xKhX9M0gziH6PKiryuxe8rah8RSFJf3WfCu1N 1uxoxuymgifKkFkE9oSCTNSdaOzaT0oUI9TnzWvzBp2MUVFtaQlRu8qQoP/BLGnA3mQyTz Sr7jk1DklxCU2UgdJ6TVSB0RsGUkj+oKH3MHICFplkH8MYOcGPcS0C/JTNT0ksXlReVTHk T9tVQRS1SZP2t6yZm3gNqEIKNB0KtMVbo2KsCJ7J2irZUh67xp5QRZv72RJOAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1710774166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vsfsoefn/iO/rlRFhdGx8bE9Eu4elkiQlMO1gEJIgAg=; b=BIOr79EGmqRpR/rk9G/xypX/PLuEG7PVBphrg5sxj+H+OacQM7+g0DsH7ZNP+kF0j0K3vE 5e0Ij1kd7W1duRyRfCAqHUaHYRHjlg6vLPhDlPJJd6aA+zhirmWpxWPtzktOAO1m2H6Hpn aHigT1pYna5Xkc9l72F/28QElLrC/zd6lAwBuObNktnD/4El5NuG0EWXnuozAvpVI9JS0+ gfDi14sF9cVjmVnwe4tlEYlJ0ixIMEQS972iOoHbvRcJjaHY8rRF/B6awNKfHaW3nRSQ3a f04fmo1UbSdL1uFf/qr9C0apl9b3VAQCS2rDJrOjLm1HN77KrFJxDpS/oVhhUA==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=mohit smtp.mailfrom=mohit@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1710774166; a=rsa-sha256; cv=none; b=jHFsNsWR9QkYLMgQjE9p67q7klUWcLuMOK21fBXOkAwpHeNgUIoJKEOOKYpXxX2KNladkc npFF6kelcKp9/Ws2pLswd551ZHhbuL1EaARDQfb1UFQLxHQQGvxQmU6ZeUVLYklQWe6dZb Ontxp5G7HRLR193pCS5V/oJqW9U6NGizzmFK2YbQGE4nrmVU/1tulDEIO2lgY2jgSPvSdV Pl/o0F+TBZpZ+yoBrDNmo41PAbNX6aihbWczLysgENbq3UUHS71y1X+VXeH0GDqVVDo5JX bGL9Z+SbiMA2gKqNaxU/dp6eNEmFFjr6yiZRpS5PzsHVHQm9rg4H6DPpPd6QEw==
Content-Type: multipart/alternative; boundary="------------jsNnCP4eEEc5uxybx8M2LcVL"
Message-ID: <a655dd76-62c0-4bcd-8582-6df80f1779a5@iki.fi>
Date: Mon, 18 Mar 2024 20:32:38 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Bron Gondwana <brong@fastmailteam.com>, secdir@ietf.org
Cc: draft-ietf-jmap-sieve.all@ietf.org, jmap@ietf.org, last-call@ietf.org
References: <171074230051.11621.14080582299477917640@ietfa.amsl.com> <12f5d211-3b84-4f12-be3c-a5c15c720af0@app.fastmail.com>
Content-Language: en-US
From: Mohit Sethi <mohit@iki.fi>
In-Reply-To: <12f5d211-3b84-4f12-be3c-a5c15c720af0@app.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/vYcvhwc50EeNNGYq0rTfK1pvDBU>
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 15:02:54 -0000

I wasn't thinking about intentional modification. I was simply wondering 
how is integrity of a binary blob ensured during transit and storage.

After some further poking around, I think RFC 9404 answered all my 
questions. It shows how the binary blobId is generated from the blob 
content using one of the supported digest algorithms (like SHA1): 
https://datatracker.ietf.org/doc/html/rfc9404#section-4.2.1. It also 
mandates encoding the blob content in base64.

--Mohit

On 3/18/24 16:54, Bron Gondwana wrote:
> 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
>
>

v2.23.0 | Report a Bug | By Email