Re: [Last-Call] [art] Artart last call review of draft-ietf-lamps-e2e-mail-guidance-14

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 13 March 2024 20:48 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E0DC14F619; Wed, 13 Mar 2024 13:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b="bexAnTOq"; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b="FYbg1caq"
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 1TQoHMoHyXVl; Wed, 13 Mar 2024 13:48:14 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (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 273B5C14F616; Wed, 13 Mar 2024 13:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1710362892; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zh+NrrSGj8NOkAA9AUdYlfywXYlS/HEHqHiRBn+laqQ=; b=bexAnTOq4+btKRdntUgJ/W5p5eUjWokC9n6PH2KqApdvywWneNoUCAD1NhfsGGU8rLZAj /+5OypL/1jE1jc9Cg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1710362892; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zh+NrrSGj8NOkAA9AUdYlfywXYlS/HEHqHiRBn+laqQ=; b=FYbg1caqkfNRx0zwtsUK4RrU1yn9YnNyeQ8ZxXhLWc1K5Nj/2nMhB/Trl6whk+O38v+7w xM23Pvlj88OlJyQkspQYuSWJ+pmwiYCe5E6ai3zB6NvEYYWy5Y/iEiwaklKnyM7t17ggcXt OSACz7pgVl/zm4sCmtF3acYefuWsM4IqWKmzJVOJgkdeOxfPRc7sZZoePFBQRTjNAESnZCO PHM2CPkM39wum3d0k8dTancwhvNmzcl0Q2HfTo3hymdanvrHNaL8SUCJ4bruJhX341+dU4C vObvHZI4IoqNtl7uzBt6BhNyOrsgDQBiE84hUo0nx1zgRBWYqkBk5Qbn9ZAw==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 174C1F9DB; Wed, 13 Mar 2024 16:48:12 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id E2D8820E64; Wed, 13 Mar 2024 16:24:54 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Bron Gondwana <brong@fastmailteam.com>, Alexey Melnikov <alexey.melnikov@isode.com>, "art@ietf.org" <art@ietf.org>
Cc: draft-ietf-lamps-e2e-mail-guidance.all@ietf.org, last-call@ietf.org, spasm@ietf.org
In-Reply-To: <e7df3354-013c-4a48-932c-059cbc68483f@app.fastmail.com>
References: <170853514591.36140.8781659777953563140@ietfa.amsl.com> <cc9f4cb9-8a20-45a0-ab03-752b7c4b0ab7@isode.com> <e7df3354-013c-4a48-932c-059cbc68483f@app.fastmail.com>
Autocrypt: addr=Daniel Kahn Gillmor; prefer-encrypt=mutual; keydata= xjMEZXEJyxYJKwYBBAHaRw8BAQdA5BpbW0bpl5qCng/RiqwhQINrplDMSS5JsO/YO+5Zi7HCi QQfFgoAMQWCZadnIAUJBdtHCwMLCQcDFQoIApsBAh4BFiEE1HcEDHDCFWpcKYVJu36RAUlea/ cACgkQu36RAUlea/edDQD+M2QjnoEyu/TjI+gRXBpXQ5jCsnnp9FdYhaSSUW/vZ8kBAJByWlj A9aMfVaVrmvgcYw7jzJz+gmZspBRB++5LZ20NzRc8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PsLA EQQTFgoAeQMLCQdHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnEu/CS CeyWwC6j4ihJr2u/z6delsF1pvYW3ufgf1L538DFQoIApsBAh4BFiEE1HcEDHDCFWpcKYVJu3 6RAUlea/cFAmWnX5AFCQXZ8EUACgkQu36RAUlea/cjVwD+ONjdHM74rAa6EEiiqaPjlptiaZx CVqFYXnib6EbZARkBAPnnR8pW8vCBnDXHKu65jNqwF3aH761NaOqqMFfppg8GzjMEZXEJyxYJ KwYBBAHaRw8BAQdAjX25Fq2Q9IUFeHy6yByIQPBnFOedFliuEiCIUzJsENDCwMUEGBYKAS1HF AAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnwqKWsw56uoWVLIFcs7ZecJ gwpsSNevWCzbviKQ8yRLUCmwK+oAQZFgoAbwWCZXEJywkQdy0WHjXNS4FHFAAAAAAAHgAgc2F sdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnEIJSOxuw2y/UJmg5M3BLpN0JYjODZpXiEVFu 1byARzMWIQR0vATEPYYIS+hnLAZ3LRYeNc1LgQAAsH8BAKg1C5LK/D7pSkXCD+jfTSP+CqM58 iHLjh4vKhpOKsTJAQCHldtEjxJ1ksPTFgG9HihHH7qc6/wvvLw77ETMpwlrAxYhBNR3BAxwwh VqXCmFSbt+kQFJXmv3BQJlp1+rBQkCF4lgAAoJELt+kQFJXmv3ydsA/2roQZ2Jm/7iUrg/2C5 ClWA/xbvPC31LyMkGGH2/rq8tAP9BgqLuCPnNTVPqeX9+9qqMmaFq7wmvjq5I+yycAw9CDc44 BGVxCcsSCisGAQQBl1UBBQEBB0BZMsRrRaaeFSYMF1ZdfRmVgBriDUIr99eDQ085BK14DgMBC AfCwAYEGBYKAG5HFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnsazAWX tEHUPmSTmcRZAIsAsNiO8k0hdjsfRlRVipgJgCmwwWIQTUdwQMcMIValwphUm7fpEBSV5r9wU CZadfqwUJAheJYAAKCRC7fpEBSV5r90AjAPwLgY1iKiFJEj32SVD5f721929l79VxQB5FlQss x1n5kQEA6Uct2tPvbB6T7p5KG3Gl+tbi7oJAuxFmpkpW5/N2Owg=
Date: Wed, 13 Mar 2024 16:24:53 -0400
Message-ID: <877ci5anhm.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/YG2e8DI71wHFsPibazkxsdzm4RY>
Subject: Re: [Last-Call] [art] Artart last call review of draft-ietf-lamps-e2e-mail-guidance-14
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 20:48:19 -0000

On Thu 2024-02-22 10:08:10 -0800, Bron Gondwana wrote:
> On Wed, Feb 21, 2024, at 09:29, Alexey Melnikov wrote:
>> On 21/02/2024 17:05, Bron Gondwana via Datatracker wrote:
>>> I do have some concerns about the implementability (particularly, as already
>>> called out in another review, the "strip things which aren't secure enough when
>>> quoting for reply" which will likely make users feel there's something wrong
>>> with their client).
>
>> What do you mean by "implementability"? This is not going to be that
>> hard to implement, it might just be surprising to users.
>
> That's enough that high-usage clients won't implement it, because the
> support load becomes too high.
>
>> Would showing a warning to the user be a better thing instead?
>
> I'm not sure that there is a better thing; maybe the user needs to be
> offered a choice.  Probably: "always include", "always exclude", or
> "always ask (default)".
>
> I think just a "this is going unencrypted: remove text that came in
> encrypted?" non-blocking prompt.

I think offering such a prompt to the user is within the bounds of the
behavior described in the document ("the composing MUA SHOULD strip the
quoted text from the original message"), though I'm always reluctant to
offer users choices that they might not have enough information to
understand and are likely to click through without reading.

That said, your proposed prompt is more readable than the overwhelming
majority of user prompts i've seen related to e2e-encrypted mail, and it
does seem like it might avoid some of the support load that unilateral
text stripping in this circumstance might inflict on the vendor.

Would you care to suggest text for the document that would encourage MUA
implementers to consider this kind of prompt?

Would it make sense to change:

   In this circumstance, the composing MUA SHOULD strip the quoted text
   from the original message.

to:

   In this circumstance, the composing MUA SHOULD strip the quoted text
   from the original message, unless the user indicates that they are
   deliberately including previously confidential content in a
   non-confidential message.

I'm proposing this change in
https://gitlab.com/dkg/e2e-mail-guidance/-/merge_requests/12 -- i'd be
happy to see suggestions for improvement.

A proper UX design (probably outside the scope of IETF work) for such a
prompt might look like a prompt that would block sending, but not
editing.  That way user has to resolve the prompt before they click
"send" and they can't send confidential text in the clear by ignoring
the prompt.  It should provide an indication to the user of what text is
going to be stripped.  And the "always include" or "always exclude"
choices shouldn't be offered directly in the interface unless the prompt
has been presented to the user several times within a relatively short
timeframe.

      --dkg