[Last-Call] Re: draft-ietf-emailcore-as-28 ietf last call Secdir r eview

S Moonesamy <sm+ietf@elandsys.com> Tue, 28 April 2026 17:46 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: last-call@mail2.ietf.org
Delivered-To: last-call@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A0956E4F2020 for <last-call@mail2.ietf.org>; Tue, 28 Apr 2026 10:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777398362; bh=W01I7pndROgMHwNxsLdj16yDVC/8p4wG7BNwED0Eam4=; h=Date:To:From:Subject:In-Reply-To:References; b=XJsuEM5JcfVOel+aIEaWIDd6lVs4FJEzkb0rWX/Cwud790d76A55rpkx/rGfyTMvz L+Oucb1TISo72QrzvARpHo7JR5di4VfdwDFunazwJGT1MTJk03gBdV6V6cmzOen1Xr Tc5SsYLHEAosItNAI3DkaGvy9qCbgByeqRnS596I=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 rraxni8ci5qW for <last-call@mail2.ietf.org>; Tue, 28 Apr 2026 10:46:01 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail2.ietf.org (Postfix) with ESMTP id 986B8E4F1FEC for <last-call@ietf.org>; Tue, 28 Apr 2026 10:45:48 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.85.71]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 63SHj1uk029109 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2026 10:45:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1777398338; x=1777484738; i=@elandsys.com; bh=W01I7pndROgMHwNxsLdj16yDVC/8p4wG7BNwED0Eam4=; h=Date:To:From:Subject:In-Reply-To:References; b=v6lXHo7tr0pOTgdIPOhIhs5Bh3h9gTxmri9B9xYCobc2SxFoFHWtLAjhY5lru4KZO EYfIoHHJ9Q38NTbrPoSrNLGM7LMOMqM1JmQHh/JxZ0MTKlLvwIx+EdPvOJbspDehC6 pDEpTFkgWRDiS2jzi/CxZvtQJl8XpJ0qzcl3i1KY=
Message-Id: <6.2.5.6.2.20260428092425.0d2295e0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 28 Apr 2026 10:26:33 -0700
To: Shivan Sahib <shivankaulsahib@gmail.com>, last-call@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <177735548849.818.15891659530280505461@dt-datatracker-b4594 9c58-t72jx>
References: <177735548849.818.15891659530280505461@dt-datatracker-b45949c58-t72jx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID-Hash: 2UDZWMNVSJF2INBY7BVX5VASUNRPZM7J
X-Message-ID-Hash: 2UDZWMNVSJF2INBY7BVX5VASUNRPZM7J
X-MailFrom: sm@elandsys.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Last-Call] Re: draft-ietf-emailcore-as-28 ietf last call Secdir r eview
List-Id: IETF Last Calls <last-call.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/hdmcfDTpW_KplmGVn9LcKfRGx34>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Owner: <mailto:last-call-owner@ietf.org>
List-Post: <mailto:last-call@ietf.org>
List-Subscribe: <mailto:last-call-join@ietf.org>
List-Unsubscribe: <mailto:last-call-leave@ietf.org>

Hi Shivan,
At 10:51 PM 27-04-2026, Shivan Sahib via Datatracker wrote:
>My remaining issue is still with Section 6.5 (Confidentiality Requirements),
>which was extensively rewritten and discussed.
>
>Section 6.5 establishes three normative requirements:
>
>1. Confidentiality (e.g., STARTTLS) MUST be implemented by SMTP servers.
>2. Confidentiality MUST be used when sending if it is available and 
>accepted by
>the receiving server. 3. SMTP-receivers MUST be configurable to allow for
>receiving messages without specific confidentiality mechanisms, or 
>even without
>confidentiality.
>
>I support requirements (1) and (2) but not (3).
>
>Using MUST for the cleartext-reception configurability requirement seems
>unnecessarily strong. Why are we *mandating* implementers to support 
>cleartext?
>I understand that there are many providers who don't or can't support TLS, but
>then this should be a MAY or similar. I don't think the current state or
>statistics of deployments changes anything here; IETF shouldn't mandate
>implementers to not have confidentiality for compat reasons. Mandating
>plaintext for compat reasons in an RFC seems like a security anti-pattern. I
>also noted the concern about "possible future regulatory requirements... could
>result in bans on confidentiality mechanisms in some countries". This again
>seems unconvincing as rationale to require cleartext.
>
>I know this topic has been discussed to death, and the WG generally feels like
>we're quibbling over not-much, but with my SECDIR hat on I have to call this
>out as having issues (or one issue in particular).

I'll comment on (3).  I don't have any problem with you calling out 
the one issue.  There was one or more comments about not having (3) 
might break email.  A community could move forward without (3) if it 
is okay with taking responsibility for breaking email in some part(s) 
of the world.

I did a little reading and I came a few countries where there were 
regulatory controls on cryptography.  I don't know whether those 
regulatory controls are enforced or not.  I don't have a strong view 
on the matter as I am not in one of the few countries.

Regards,
S. Moonesamy