[Last-Call] Re: [Emailcore] SECDIR Review of draft-ietf-emailcore-rfc5321bis-31

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 29, 2024 at 09:52:11AM +0100, Ted Lemon wrote:

> Most end users wouldn't even think to check this or have reason to think
> they were at risk, because encryption on the wire is pretty much de rigueur
> for every messaging protocol _except_ SMTP.

Well, we still have "HTTP" (without the "S"), which is *explicitly*
cleartext, while SMTP transport encryption is an opportunistic option
between the sending and receiving MTAs, and the vast majority of SMTP
traffic over the public internet is now encrypted.

> The argument presented here for not requiring STARTTLS is essentially the
> same argument we could have made about not requiring TLS for HTTP. Clearly
> the industry has decided there. The industry has mostly also decided on
> STARTTLS. Now is a good time to make this change.

Whether the IETF decides that STARTTLS is required is rather secondary
to the choices made by MTA operators.  Indeed it appears that a larger
fraction of (GMail) SMTP traffic is encrypted than the share of Web
encrypted Web traffic in Chrome usage surveys.

    https://transparencyreport.google.com/safer-email/overview?encrypt_out=start:1356912000000;end:1730159999999;series:outbound&lu=encrypt_in&encrypt_in=start:1356912000000;end:1730159999999;series:inbound
    https://transparencyreport.google.com/https/overview?hl=en

Yes, these are not exactly apples-to-apples comparisons, but it is still
I think a fair basis on which to conclude that mandates aren't the only
way to nudge adoption of transport security, if it is easy enough to
turn on, and auditors and independent reviews flag non-compliance, then
over time the industry moves to adopt best-practice.

Of course, given the now near universal adoption of STARTTLS over the
public Internet, the SMTP A/S for the public Internet can emphasise that
STARTTLS is now the expected norm in this space.

-- 
    Viktor.

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux