IETF Last Call Review of draft-ietf-emailcore-as-26
review-ietf-emailcore-as-26-secdir-lc-sahib-2026-01-05-00
review-ietf-emailcore-as-26-secdir-lc-sahib-2026-01-05-00
SECDIR last call review of draft-ietf-emailcore-as-26 "Applicability Statement for IETF Core Email Protocols" Reviewer: Shivan Kaul Sahib (SECDIR) Review result: Has Issues. --- This Applicability Statement is generally accurate and, importantly for SECDIR, it does not introduce new protocol mechanisms. Security/privacy considerations are discussed throughout, with the material concentrated in Section 6 (confidentiality/authentication for SMTP) and the Received-header privacy guidance in Section 3.2.1. The Security Considerations section is short but summarizes the security-critical concerns. Section 6 is mostly okay. It correctly frames hop-by-hop TLS, downgrade attacks with STARTTLS, and the role + limits of RequireTLS/MTA-STS/DANE, as well as message-level mechanisms. --- Minor: In Section 3.2.1, the draft says: "Email addresses are commonly classified as Personally Identifiable Information (PII)". I suggest using IETF-standard privacy terminology and deferring to RFC 6973, replacing "PII" (a US-centric privacy term) with "Personal Data" (as defined in RFC 6973, also used in GDPR), or simply "personal data". RFC 6973 defines Personal Data as "Any information relating to an individual who can be identified, directly or indirectly." --- Nit: s/Javascript/JavaScript in Section 4.3. --- Nit: Section 6.1.2 says opportunistic TLS falls back "if a secure connection cannot be established." Consider changing "secure" to "TLS-protected" (or similar). --- Minor: Section 6.1.2 asserts "the vast majority of email traffic is encrypted during its time transiting". This seems like it needs a citation. --- Section 6.3 describes SMTP AUTH and notes the common username/password configuration for submission. It would be worth adding a sentence making the security property explicit (e.g., credentials MUST NOT be sent without TLS, and deployments should require TLS for AUTH). --- Section 6.5 says "confidentiality... MUST be implemented", and then says servers "servers MUST be configurable to allow for receiving messages without confidentiality" for interop. This is a bit confusing. --- When discussing STARTTLS, the draft doesn't mention anything about minimum TLS version to use. Should there be a reference to/dependence on RFC 8997 (or perhaps RFC 9325) here? --- Thanks, Shivan