Re: [Emailcore] Re: If some government makes STARTTLS illegal

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

 



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
Internet, without any push in that direction in RFC5321, so it is not
clear that any benefit will acrue from mentioning STARTTLS in the
security considerations of the base SMTP specifcation.

Meanwhile the A/S will codify this fact, and indeed strongly recommend
STARTTLS (once some technical details are corrected).

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.  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

    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)

Perhaps the chairs can seek or give some clarification?

-- 
    Viktor.




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

  Powered by Linux