Hi, Victor,
On 2/11/24 00:34, Viktor Dukhovni wrote:
On Fri, Nov 01, 2024 at 11:37:42PM -0300, Fernando Gont wrote:
On 1/11/24 19:14, John C Klensin wrote:
[....]
IMO, the strongest argument for "encrypt everything" is the one Barry
mentioned: relative to only encrypting selected messages, it
considerably increases the burden on anyone would wants to inspect
messages by requiring them to try to decrypt all them.
It is not just that. Where encryption matters the most, and where it is not
mandatory for all communications, the use of encryption (itself) is a public
signal that you have something to hide to those are are supposed to be
snooping.
Exercise: go offer a public and open course on encryption technologies where
people are oppressed, and see how many show up -- and not as a result of
lack of interest.
But STARTTLS is *already* nearly universally deployed on the public
Sorry, I was referring to encryption in general.
IN any case, deployed != mandatory. And if not mandatory, those willing
to intercept messages may simply try to make the fall back to
non-encryption. (e.g., think of HSTS for HTTP)
The main justification I can see to include STARTTLS in the
specification is if the goal is not just to suggest STARTTLS as a
potential defense against a highlighted threat (security
considerations), but to make it a SHOULD or MUST requirement in SMTP.
It is no longer clear to me what this thread is about.
Same here :-) -- since the thread was moved here from elsewhere.
Are we
discussing:
1. Raising awareness of the threat of passive monitoring and
STARTTLS as a potential work-around in the security
considerations (aligment with RFC7435), or
STARTTLS is not really a workaround. If you are concerned about email
eavesdropping, you should use e2e ecncryption for the payload. Then,
whatever you want to add in addition to it, fine.
2. Raising the bar in the protocol to make use of STARTTLS
a SHOULD (unless good reasons). Concretely is this about:
a. MTA implementations including support for STARTTLS
that operators can choose to enable or (if on by
default) disable?
[Implementation]
b. Receiving MTAs making sure to offer STARTTLS?
[Operations]
c. Sending MTAs being sure to use STARTTLS, when offered?
[Operations]
d. Sending MTAs insisting on STARTTLS support and bypassing
MX hosts that fail to offer it?
[Operations]
And would any of 2.[bcd] be a MUST?
([2.d] Makes cleartext SMTP non-conformant with the specification)
Not sure what is being argued here. probably something to mandate use of
STARTTLS. BUt then,
- it doesn't solve the entire problem,
- it's not a backwards compatible change
THanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
