[saag] Re: Initiating discussion on normative evolution of e mail protocols to enforce mandatory encryption and digital signat ure

Hi.

Thanks for starting this discussion.

I agree that email is, as you say, a cornerstone of digital communication, and has been for decades. Despite all kinds of instant messaging, video conferencing and social media, email remains the primary method that people communicate outside of their organization. I mostly want to talk about your objectives, but I think a big one is to keep email useful.  I think there are three important properties of email that make it last:
That it is federated - nobody is in charge and can take away your email, and anyone can set up an SMTP server and connect. Well, close enough to anyone.
That it is store-and-forward - you don’t need to have sender and recipient online at the same time to send a message. In fact, you can have neither sender or recipient online.
That it is very accessible - anyone can get an email address for free.

I don’t think what you wrote in the problem statement is quite correct. Most countries have laws about medical records and financial information. At least in my country they can’t send it in email. Instead I get a cryptic message from my healthcare provider that I have new information on the website. I then have to go on the app or the website to see that new information. I would be glad if we could make it so that we didn’t need this work-around, but it’s not certain that you can achieve this with standards documents. The practice of leaving MUAs open and showing message previews as the messages arrive is so common that regulators can’t ignore it. We could mandate encryption of the data in transit and at rest and the regulators would still prohibit sending sensitive information to private email accounts.

One more thing to consider, the vast majority of email users do not own their own server. They use either a cloud service email provider (like gmail, live.com <http://live.com/>, office365) or an email server provided by their employer. Maybe some are still using an ISP-provided email. This is important because if you believe that I am who I claim to be, then you are trusting gmail to verify my identity.

But on to your objectives. You want an Internet Draft that will do the following:

> - Mandate encryption of email content, beyond opportunistic TLS, ensuring
> confidentiality at rest and in transit.

Putting those two things together is confusing. TLS, whether opportunistic or mandatory, works only in transit. If the message is not encrypted, then it’s available in the clear to every SMTP server on the path from the sender’s MUA to the recipient’s. Any one of those SMTP servers could be compromised to leak the message. 

> - Require digital signatures for all email messages, to guarantee integrity
> and authenticity - even in cases where encryption is not applied.

In the previous bullet point you mandated encryption. What are these cases where encryption is not applied?
And this is where you raise a significant barrier to entry for email. Clients in general don’t have certificates. This is certainly true on the web. And it’s rare outside of corporate or government silos in email. And it’s rare for a reason. Email is complicated by people using multiple MUAs to access the same email account (on a laptop, a phone, and a web interface), and people sign up for email accounts with no linkable identity. So what would a certificate for [email protected] <mailto:[email protected]> prove about me? Yes, the big providers are trying to get more PII on you. I don’t think that this is a good thing. 

> - Define a standardized mechanism for public key discovery, such as
> DNSSEC/DANE or a federated PKI.

That is yet another barrier for entry.

> - Introduce a new MIME header indicating encryption/signature requirements
> and compliance.

Now you’ve done the engineer thing of diving into solutions in the requirements document. But again, if we have encryption / signature requirements indicated in a MIME header, then I guess those mandates in the first two bullet points are not really mandates.

> - Establish a transition roadmap toward deprecating unencrypted and unsigned
> email delivery.

Sure, but let’s first figure out where we want to go, and then talk about how to get there.

I apologize if the above looks confrontational. I think we should be very clear in what we want to achieve, and what price we are willing to pay to achieve it. The move of the web from cleartext to TLS was remarkable in how little disruption it caused users. I don’t know that we can make it quite as painless with email.

Yoav


> On 9 Oct 2025, at 7:26, adums <[email protected]> wrote:
> 
> Greetings,
> 
> 1.  Background
> Email remains the primary electronic communication channel used across
> public institutions, private enterprises, and personal exchanges. Despite
> its ubiquity, the underlying protocols (SMTP, MIME, etc.) do not enforce
> encryption or authentication of message content by default.
> Existing standards such as S/MIME (RFC 8551) and OpenPGP (RFC 4880) provide
> mechanisms for encryption and signing, but their adoption remains limited
> due to usability challenges, lack of interoperability, and absence of
> transparent integration in mainstream email clients.
> 
> 2.  Problem Statement
> Highly sensitive data - including medical records, legal documents, and
> personal identifiers - is routinely transmitted via email in plaintext,
> exposing users to interception, manipulation, and privacy breaches. This
> situation is incompatible with modern expectations of confidentiality and
> data protection, especially under frameworks like GDPR.
> 
> 3.  Objective
> This proposal aims to initiate a formal discussion within the IETF community
> to explore the creation of an Internet-Draft that would:
> - Mandate encryption of email content, beyond opportunistic TLS, ensuring
> confidentiality at rest and in transit.
> - Require digital signatures for all email messages, to guarantee integrity
> and authenticity - even in cases where encryption is not applied.
> - Define a standardized mechanism for public key discovery, such as
> DNSSEC/DANE or a federated PKI.
> - Introduce a new MIME header indicating encryption/signature requirements
> and compliance.
> - Establish a transition roadmap toward deprecating unencrypted and unsigned
> email delivery.
> 
> 4.  Technical Considerations
> While implementation details are open to discussion, potential directions
> include:
> - SMTP extensions that reject or encapsulate unencrypted or unsigned
> messages.
> - Mandatory support for S/MIME or OpenPGP in all major email clients, with
> simplified key management.
> - Compatibility with existing anti-spam and authentication mechanisms (SPF,
> DKIM, DMARC).
> - Integration with secure transport protocols and metadata protection.
> 
> 5.  Call to Action
> This is a citizen-driven initiative, not a finalized technical draft. Its
> purpose is to encourage IETF members to consider drafting a formal
> Internet-Draft addressing mandatory encryption and signature. Invite
> feedback from protocol designers, security experts, and client developers.
> Raise awareness among users and professionals about the risks of plaintext
> and unsigned email.
> To the best of my knowledge, no RFC has yet proposed a mandatory
> encryption-and-signature framework for email protocols as a normative
> requirement. If such a proposal exists, I would be grateful for any
> references.
> 
> 
> 6.  Closing Thoughts
> Email is a cornerstone of digital communication. It is time to align its
> technical standards with the ethical and legal imperatives of
> confidentiality, integrity, and trust. This proposal is a starting point -
> and I hope it finds resonance among those with the expertise and influence
> to carry it forward
> 
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]