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
