Indeed, it's hard to see a downside to requiring STARTTLS. I had a major panic the other day because someone emailed something quite private to me and I had to really work to figure out whether or not it had gone over an encrypted connection (fortunately it had, although don't get me started on the in-place security). If there is still SMTP mail not going over TLS, is that something we ought to feel bad about breaking? I would argue not.
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.
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.
On Tue, Oct 29, 2024 at 2:21 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Mon, Oct 28, 2024 at 08:09:50PM -0400, John R. Levine wrote:
> I would have hoped we would agree that we do not want to make breaking
> changes to a widely deployed 40 year old protocol. While it is true that
> most mail over the public Internet uses STARTTLS, you and I do not know all
> of the places SMTP is used, it's always been an optional feature, and we at
> least used to give lip service to maintaining interoperability.
PGP and S/MIME don't encrypt the envelope, and IIRC at least S/MIME does
not encrypt the message headers including subject. For confidentiality,
STARTTLS is the foundation on which these rest.
And frankly, there are as yet no mail user agents that make PGP and
S/MIME portably usable, by reencrypting the content to a recipient key
upon first access for long term archival *and* search. So I for one do
not want to receive S/MIME or PGP messages unless they're short-term
throw-away content.
Email security is a complex interplay of data in motion and data at rest,
and a brief detour can do harm through misrepresentation. A detour with
appropriate caveats is not easily achieved.
That said, a recommendation to implement RFC3207 is at this point quite
defensible. Though there are complex questions about the details, which
are surely out of scope, but without addressing them, it is unclear how
actionable the advice to do STARTTLS might be:
- What to do when STARTTLS is not offered
- What to do when STARTTLS is offered, but the TLS handshake fails
(real world examples: peer supports only outdated TLS features,
TLS 1.0, TLS 1.2 without EMS, peer certificate keyUsage lacks
"digitalSignature", some day lack of TLS 1.3).
- If enforcing STARTTLS, defer and keep trying (better, but long
delay before sender learns of the problem), or bounce on first
failure (much too fragile, but timely)?
...
It may be time for RFC3207-bis, where transport security can be covered
in more detail, based on lessons of the last 22 years.
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
