IETF Last Call Review of draft-ietf-emailcore-as-28
review-ietf-emailcore-as-28-secdir-lc-sahib-2026-04-27-00

This is a follow-up to my SECDIR review of -26. The -26 SECDIR review is at:
https://mailarchive.ietf.org/arch/msg/emailcore/emgyDk2IdYENmU0rAE01YL9FJC0/

I reviewed the diff between -26 and -28, the working group discussion, and the
supplementary Last Call thread.

Most of the concerns from my -26 review have been addressed: thanks to the
authors for that.

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).