[Sml] Re: Adoption call for draft-happel-structured-email-trust-04

Lisa Dusseault <lisa@rtfm.com> Wed, 30 July 2025 18:11 UTC

Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: sml@mail2.ietf.org
Delivered-To: sml@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 933464D746AD for <sml@mail2.ietf.org>; Wed, 30 Jul 2025 11:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.017, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SK--eiXHs4l for <sml@mail2.ietf.org>; Wed, 30 Jul 2025 11:11:17 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8390B4D746A3 for <sml@ietf.org>; Wed, 30 Jul 2025 11:11:17 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-e8e1aac03eeso113770276.3 for <sml@ietf.org>; Wed, 30 Jul 2025 11:11:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1753899077; x=1754503877; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zE1JCxVIUCxu41Nhx+V7CKHL23O12HopAlyDTGFjz8g=; b=as2H032lgDu8N2LLuydIgO74Ln+noqsD83tAHVTK/KszCeLQhfzP/zAG0L0g4JXiP9 Hj6+2gGmpk7ipLZXL9rAURqeNHzX0o0oXI1P09xFn46qQ55kw1++nNQWZdpjXB08lvYR trpizsGxJg4J86uwgkwU39t1Q6n/9gCnnylUzjso1B3PvP9KGrUX8jHVWOwwmIrcRO1r 6tdL9+LrMeo+6aKv5BinxT2GpWTyXUPNp4YEwSifXo8v97FjmlF9a6fWcpCgVl6xOMcn EEtj2Yt99fUKSRkK+iAJGpfHaIPMHLmiqDNTtT2YIUycGSssvg8fzGYOCSENuwa04oU8 8e+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753899077; x=1754503877; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zE1JCxVIUCxu41Nhx+V7CKHL23O12HopAlyDTGFjz8g=; b=uWbVmGT6FrvbMCSuT645kfJwMaLkOTxCNWiC/vkSbXm6YOs02ni8tJdIBEXm741e/X NYr6BYXE3+tjVRUipypAAIm3Hao9xCQxqQvzqaoTBJaeUVlOYSO/0uMLR1VqFP9doSXC A7eAz+isU9uQsV6j4BzvTF3e5ROq5f7qe29IF2mPXxCVlJ7lQK61z38f6ANr2zI9scAO eCHEMv54dG6OAdrD2tsXsL19J/F/A1dQEYcs/bmATBwsGTqUx7Z0tEPpnaZr8YfFealo eU3XqPg0udpnHXwG37GdAwSnGZ8ZkgXVLwTYkPiZeDviwsSpL/AOmWKMQME4/ihMLAhu k/bw==
X-Gm-Message-State: AOJu0YximE0s67mab4oZwmGpBqYv8OKu3n5aqCXwwIqLzfKzX6Bfiz0A rJGY7g+88LBZWlzRvwQJWXm7WlJhmPlCx0DmSqILCcgCGbEt70nh1CFZP2guIM/z9qj9ghaBGMO iGN5KJl7de8Cn7ws/guLLm9xkBLEJ2YZLjE6O
X-Gm-Gg: ASbGncubt2NdVi8QHT9np7QDbHWUo6ln1F6tuOxl2uxqpAUQ1PTaDjeElCbt9sv9m6M XmEnpLMW5mH/J2jkAmVWHRtvDGlWSnYzQ0D3xdUpZd0FAYlFvAbLxX8RXIcwHY3/o5tKJWGZHfD CAR2VqLNGEJmbKPMJ3sjKmyV1Mv3m3wm7VJYGNCha/hC4vi9cWxynxyDyHKu1dP0UVmTCqvt8yY +5D//HCDw==
X-Google-Smtp-Source: AGHT+IELGmT1OHIvQyOVrgqY14wn9xrSHp87yvuyO8VsrG+ApZEhUtivyMuzD+AkEv674tjY34JUCm0HwJ5hIEJvmSM=
X-Received: by 2002:a05:6902:1693:b0:e8e:2476:5c47 with SMTP id 3f1490d57ef6-e8e314a4da0mr5312333276.13.1753899076720; Wed, 30 Jul 2025 11:11:16 -0700 (PDT)
MIME-Version: 1.0
References: <b003edfa-5902-44e2-8c91-dedf18558ef7@isode.com>
In-Reply-To: <b003edfa-5902-44e2-8c91-dedf18558ef7@isode.com>
From: Lisa Dusseault <lisa@rtfm.com>
Date: Wed, 30 Jul 2025 11:11:04 -0700
X-Gm-Features: Ac12FXxPnCZlU0QMB7BA2jTl95v62TJVtQoBDthoOM9GuEhWXmPcbX--JEpxSmY
Message-ID: <CAEi+uC4fAu85rEomfQN-u-eZq8Efi2uDEx8vEb2r7_r214mk6w@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary="00000000000070a62a063b297385"
Message-ID-Hash: TNYSVWGDDT7YRN2EQB6ZO7PAPOMKXO5V
X-Message-ID-Hash: TNYSVWGDDT7YRN2EQB6ZO7PAPOMKXO5V
X-MailFrom: lisa.dusseault@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: sml@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Sml] Re: Adoption call for draft-happel-structured-email-trust-04
List-Id: Structured Email <sml.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sml/LCMTA1C-aETO4QvRNdLv-_dgsns>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sml>
List-Help: <mailto:sml-request@ietf.org?subject=help>
List-Owner: <mailto:sml-owner@ietf.org>
List-Post: <mailto:sml@ietf.org>
List-Subscribe: <mailto:sml-join@ietf.org>
List-Unsubscribe: <mailto:sml-leave@ietf.org>

I'm in favour of adopting this document as a WG document though I can't see
why it's not a section of the main framework document.  It's in such
conversation with the work in that document and should be. I'd be even more
in favour of merging.  I also think the expired use cases document is
necessary to understand this.

Comments on the material itself:

I don't think the work on including and passing around secrets in email
(section 4.5) is mature or necessary.  It's very tempting to try to improve
the security of a system while we try to standardize it but I don't think
this is it.  It adds a lot of concerns about how the secrets are generated
and by whom.  If the attacker can guess how invoice numbers are generated
and then use those to build trust, this just adds even more security
concerns.  This may be more mature than I know in some implementations or
designs out there, but I can't tell from this document and I don't think
it's needed.

The plan to use Trusted Senders and the user's address book  to establish
trust (section 4.1) is not a good one.  The list of email addresses I send
to is NOT the list of email addresses I trust - there are many false
positives as well as false negatives.  It opens paths for targeted
attacks:  once a user is convinced to email a recipient (even to protest
something!  Even to complain or report a security issue!) now the recipient
KNOWS who has them in their address book and can try sending them a
structured mail involving fraud. Address books are  merged and populated
from multiple sources and not all those sources can be equally trusted.
Again, I don't think this is necessary.  Email recipient software already
decides how much parsing of an email to do and what to do with the results,
whether to add an event to somebody's calendar or offer an affordance to
use the parsed data.

Lisa

On Sat, Jul 26, 2025 at 12:31 AM Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

> Dear WG Participants,
>
> This email starts a two week Call For Adoption for "Trust and security
> considerations for Structured Email" (
> https://datatracker.ietf.org/doc/draft-happel-structured-email-trust/) as
> a starting point for a WG document.
>
> Please respond with your feedback, whether positive or negative, by the
> end of August 10, 2025. In your feedback, please be clear which comments
> need to be addressed before adoption and which comments can be resolved
> once adopted. (Full reviews are also welcome at this point, but please
> label comments appropriately)
>
> Reminder: This only constitutes a call for adoption of the document in its
> current form as a starting point for WG output.
>
> Best Regards,
>
> Alexey, as a co-chair
>
>
> --
> Sml mailing list -- sml@ietf.org
> To unsubscribe send an email to sml-leave@ietf.org
>