Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

Scott Kitterman <sklist@kitterman.com> Mon, 18 July 2022 21:34 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: bimi@ietfa.amsl.com
Delivered-To: bimi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24702C15790C for <bimi@ietfa.amsl.com>; Mon, 18 Jul 2022 14:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nFyK7XWx; dkim=pass (2048-bit key) header.d=kitterman.com header.b=A4Vndoek
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 gYjx-xVTmOfh for <bimi@ietfa.amsl.com>; Mon, 18 Jul 2022 14:34:22 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B248C14CF15 for <bimi@ietf.org>; Mon, 18 Jul 2022 14:34:22 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 8D852F8031D; Mon, 18 Jul 2022 17:34:17 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1658180057; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=EGUcpRPkqUjPUNlwbKGnKUgi09GEHBU0kD4u3Z8V7UA=; b=nFyK7XWx4HUmxYbt/qgkUAGVJUsCVgTnZxCfCM/fJdggZl3DdGvb+5uu/G5wRentFNitN u1+F6hpcZqukigGAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1658180057; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=EGUcpRPkqUjPUNlwbKGnKUgi09GEHBU0kD4u3Z8V7UA=; b=A4VndoekjkZZleLigH8L/57HNj7fxXrytCx7JlyB/5avbewE8moudpxYTxNq3f9/QchOs mnNxWZjmQJ0a7htHbg8NQrVoNpUsFeu062WcBjFiPUhQH87zxVOlaFJNrqe1WD1xNBWdmSI AScD4Z32nVwho4D8CWJjPhzQwX+oZAL4JJcbCYRhHhXJ7rlmVyACbA9yfsbIG1FLcvmcyu4 N2mEf7iOl4bDyoVCcrBgynyU4vQjGJisO/+/G0901xIJ+nsNa4JcE3Pq2qe2AK0trDJwJSm Y+PET2eB6aQUHFcTQIcuuoyI9qxi8YJdQXclIn7x4WyV3n5rk8hXY9VjjTcQ==
Received: from [127.0.0.1] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 577B3F8023D; Mon, 18 Jul 2022 17:34:17 -0400 (EDT)
Date: Mon, 18 Jul 2022 21:34:18 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: bimi@ietf.org
In-Reply-To: <7e0642ce-17ed-f87a-d15f-74acb690b93e@dcrocker.net>
References: <DE61AC51-4BC3-44FF-862D-7D8ADFB3BC29@proofpoint.com> <20CBD506-7E50-4161-ADE6-64614630B1B2@proofpoint.com> <CAHej_8kridbc322MDRpxfgd+8Y2yNacxTAtvr+HF=+wevdRQhw@mail.gmail.com> <VI1PR01MB70538965904FD08A49F75C37C78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <11A2B052-A26C-4A9C-9D88-72B594DA1C59@proofpoint.com> <VI1PR01MB70537BA29DA1F456B858C17FC78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <6993E8B6-11A0-4AF3-A94E-044F880E56BC@proofpoint.com> <CAHej_8kjwtGE4rDrXfTpgThOD-jh7t0GK9EUnVjVZT_OJzzsvg@mail.gmail.com> <VI1PR01MB705353E36328899609DE2471C78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <12a85dfe-664f-d757-0fa2-81f17c8088c2@dcrocker.net> <4e9ab94e-8675-df70-3e4b-00edcedb266e@dcrocker.net> <5DE65D46-853F-4F61-ADA7-20CB5E7E6840@kitterman.com> <7e0642ce-17ed-f87a-d15f-74acb690b93e@dcrocker.net>
Message-ID: <BF763EBC-6435-4DCB-BC59-A061D8973694@kitterman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/XZIyYfU46vOAIKcUt-_lR_IGbA4>
Subject: Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Brand Indicators for Message Identification <bimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bimi>, <mailto:bimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bimi/>
List-Post: <mailto:bimi@ietf.org>
List-Help: <mailto:bimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bimi>, <mailto:bimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 21:34:28 -0000


On July 18, 2022 9:23:54 PM UTC, Dave Crocker <dhc@dcrocker.net> wrote:
>On 7/18/2022 2:13 PM, Scott Kitterman wrote:
>> On July 18, 2022 8:50:15 PM UTC, Dave Crocker <dhc@dcrocker.net> wrote:
>>> On 7/18/2022 1:22 PM, Dave Crocker wrote:
>>>> IMAP and POP are examples of protocols created for MUAs.  They do not specify the way an MUA can/should implement these details or how things should be presented to users, but they very much dictate their realm of functionality.  That naturally pertains to some aspects of MUA design.
>>> Addendum:
>>> 
>>> DKIM is designed as an end-to-end mechanism.  Both ends can be implemented in MUAs.  There is nothing that dictates that any aspect of DKIM be implemented in the email handling infrastructure.  The choice to implement it in that infrastructure is operational, rather than architectural.
>>> 
>> I think that's accurate, but not particularly helpful.
>
>Thanks for the helpful assessment.  If no one needed to hear the information that's fine.  From the postings, it wasn't clear to me.  The boundaries for interoperability and specification work can be confusing.
>
>
>> Typically MUAs (standalone ones anyway) don't store the results of operations like DKIM verification.
>
>That's nice.  How is it relevant to what I posted?
>
>
>> They reparse the header and revalidate as needed when a user selects the mail.  While key management actions such as key rotation are formally outside the scope of RFC 6376, such things do happen and so the accuracy of time late verification does decline over time.  It might even be hazardous to attempt if the key size is small or the private key has been made available [1].
>
>Same question.

In theory DKIM can be (and has been) implementated in an MUA and it generally works reasonably well when a message is received, but AIUI (and maybe I don't) to be useful for Bimi such a verification would need to be reliable over time and I have yet to see it work that way despite it being (as you suggested) theoretically fine.

For something like Bimi to be a reliable indicator of anything, I think both theory and practice need to be considered (even though they're in theory the same).

Nothing worth starting a big thread over, so I'll leave it here for people to consider (or not).

Scott K