(copying the EMAILCORE list since parts of this discussion are relevant there.) --On Friday, November 1, 2024 19:44 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 01-Nov-24 18:58, S Moonesamy wrote: > ... >>> And if some government makes STARTTLS illegal ... > > ... the it simply doesn't matter whether it's a might, a MAY, > a SHOULD or a MUST in an RFC. Implementers and operators will > do what they need to do. > > ... > > As a comment about HTTPS, one of the sites which used to be > available >> over HTTPS is www.youtube.com. I cannot access that web site at >> the moment. > > This is unfortunate, but again, what we write in RFCs is rather > irrelevant in any such jurisdiction. The IETF has precisely zero > power in such a situation. Brian, First, for anyone on this list who have been lucky enough to not be following the rather active discussion about draft-ietf-emailcore-rfc5321bis-31 on the Last Call list, the source of this thread was a very active discussion about whether STARTTLS should be mentioned in in that draft and turned into a firm requirement and, in particular, a comment of mine on that thread. To your comments above, there is another issue that makes this relevant to the IETF and its decisions. The scenario in a little more detail and generalized for this list, goes approximately as follows: * Government X decides to ban STARTTLS with SMTP or, because people they are concerned have something to hide could easily find a way around that (e.g., posting to handy web sites), bans encryption entirely. Their only likely reason to doing that (I'm assuming a certain amount of logic, even if I --and presumably you, Carsten, and others reading this-- find it unattractive or worse). If, rather than only transmissions they couldn't read, they considered the whole Internet as hostile or a threat, they would likely figure out that banning email-over-TLS is pretty pointless unless they also ban HTTPS, and then try ban external connections (at least encrypted ones) entirely. Maybe in addition to, rather than instead of encryption, they were concerned about satellites and other non-wire channels, but, if blocking external communications were the goal, no point banning encryption alone. These are real issues, not hypothetical as debates about satellite Internet service to parts of Ukraine and Russia illustrate. Ok, absolutely nothing the IETF can do about any of that. And while, as Carsten pointed out [1], this affects people outside the country as well, nothing much we can do about that either. However, the reality is that most of the email traffic in the world is innocuous. As SM essentially pointed out, the combination of a large distribution list and public archives would make keeping this message secret somewhere between "hopeless" and "laughable" no matter how well encrypted the transmission channels. Similarly, if you and I had an email conversation about the relative weather characteristics in the Northeast US, the North Island of New Zealand, and parts of the UK, I can't imagine either of us losing any sleep over some government bureaucrat or spy reading those messages. If they spent a lot of time searching the messages for hidden meanings, we might even rejoice that they were wasting their time that way rather than digging into messages that might, from their standpoint but not ours, be problematic. The analogy between that story and one of the arguments for pervasive encryption should be clear -- works both ways. That is where the IETF comes in and at least one reason why STARTTLS, for example, has a fallback to cleartext. But suppose we go into the mail specs (let's leave the argument about where in that collection to the WG and Last Call list) and say "STARTTLS MUST be supported" and do so with the clear intent of "mail that is not encrypted is unacceptable on the network". Without the latter intent, required support for STARTTLS is little more than Security Theater. An implementer in a different country who decides, on that basis, to reject (or refuse to transmit) messages that don't come with STARTTLS, or where encryption cannot be negotiated, on the basis that the IETF requires those things would effectively block all email transmission (at least where their implementation is involved) in and out of the country and within it. That would be the consequence of IETF decisions and we should not pretend otherwise. That, in turn, takes us back to the discussion about draft-ietf-emailcore-rfc5321bis and related documents in that WG. The "what to put where" discussion aside, if we care about the issues above, if we are going to say "SHOULD support STARTTLS" with an explanation of those issues, that is different from saying "MUST support STARTTLS". Either should come with two explanations: (i) Fallback to cleartext MUST be supported, as the STARTTLS spec requires, and (ii) anyone who intends to use STARTTLS as a counter to pervasive surveillance of email traffic had better understand that there is an effective alternative to trying to watch network traffic that has been well-known since before the RSA and DH algorithms became generally known. Put in the context of governments trying to spy on email traffic moving in and out of the country, the easiest, and possibly most effective, mechanism is to ban any mail server receiving traffic from, or transmitting traffic to, out-of-country locations, unless it is operated or controlled/ supervised by the government, copy that traffic, and examine it at leisure. That has the advantage of having strong analogies to long-established border crossing regulations for people and goods. Of course there are partial workarounds but blocking them rapidly takes the problem the government thinks it needs to control back to the remedy of "just block all external Internet traffic". best, john [1] https://mailarchive.ietf.org/arch/msg/ietf/mX0Oy5yF2aoeRu_21cKnbmWGOJU
