On 2025-10-21 14:14, John Levine via mailop wrote:
It appears that postfix--- via mailop <[email protected]> said:
One certificate per email address/alias.
That's RFC 7929. It's still a bad idea.
Thank you for making me aware of another attempt that has not worked.
Trying something different here. I agree with you that RFC 7929 is a
bad idea. would you elaborate your reasons to consider it a bad idea?
I COULD criticize most of the relevant RFCs that have overlap with what
I am trying to shift toward and add onto MTA and away from the MUA, but
it is always cheap to criticize. I am trying to put forward solutions.
Generally: leave DANE alone, primarily because scalability. Whether
using centralized (RFC 5280 PKI) or decentralized OpenPGP (RFC 9480 <-
4880 <- 2440/2991) certificate generation, tacking an additional DNS
record per full address@domain is unnecessary, burdensome, redundant.
RFC 7929 was trying to solve one of the many problems of key
distribution. There are worse attempts out there that sadly got enough
traction to become irritating (Auto*f-ing*crypt). Unverified publishing
to a keyserver is bad. Autocrypt is worse (there was a neat Proton blog
about it). Abusing DNS to publish keys is bad too.
As stated earlier in this thread, I am not reinventing DANE, even if
there is some overlap. There is also some overlap with SPF. I intend
to police senders, and to do so I need a secure feedback loop:
* sender self-declares the nature of the message and certifies with
digital signature
* recipients express policy for what purpose they accept email and for
what not. extra bonus, they also get to require encryption. all optional.
* headers and URLs to enable human recipients to complain that received
message was misrepresented (actual nature of message different than
declared nature)
* the signals from the human recipients are systematically collected by
their mailbox-providers and passed on to the sender's ESP, both for
policing of the sender; which may include technical penalties;
economical penalties; or in extreme cases exclusion from sending privileges.
I want to use what already works and **anchor** trust in DNS, not break
DNS under a massive increase of data and queries. And I want to create
a sufficiently flexible chain of trust that works from the most
permissive to the most stringent use-case possible.
DNS
===
* trust is anchored in DNSSEC (RFC 4033) no need to reinvent the wheel
* one entry per domain (not one entry per name)
* blatantly copying from DKIM (what works works, but will probably need
a bit more work)
* one TXT record
* name _ipp[.subdomains].example.org
* value "v=IPP1; t=url; url=https://example.org:12345/ipp/";
no further damage to DNS.
* (manual) retrieval of an alias' public key (alias is only the part on
the left of the @):
curl https://example.org:12345/ipp/<alias>.pub
* (manual) retrieval of an alias' identified participant policy:
curl https://example.org:12345/ipp/<alias>.pol
* (manual) reporting of a sender's policy offense
curl
https://example.org:12345/ipp/<alias>.report/${UNIQUE_MESSAGE_TOKEN}/${FAILURE_CODE}
CRYPTOGRAPHIC SCHEME
====================
* correct me if I am wrong: there have been two relevant, competing
cryptographic schemes out there. decentralized OpenPGP; and somewhat
centralized (CA-dependent) RFC 5280 X.509/PKI
* I propose to use X.509/PKI because it is already used to secure other
aspects of the system. It also allows for the same freedom that OpenPGP
allows if self-signed certificates; and if self-operated CAs are
acceptable. Both, by design, are a recipient's choice, falling back on
system defaults. Not different than SMTP opportunistic encryption
functioning well with self-signed certificates.
ENCRYPTION/SIGNATURE
====================
* here is one major difference from existing schemes
* the purpose is to certify the message, not the transmission, the
domain, or the sender; although some of the other schemes using
encryption that have been tacked on SMTP could become redundant.
* the other major difference is to provide a tight, reliable,
automatable feedback loop. how individual operators implement such
feedback loop, is left to their choices. Your server, your rules.
* Deliberate decision: not to use existing encryption schemes because
(a) message encryption: the adoption of the various forms of PGP and of
S/MIME (RFC 9788/8551 <- 5751 <- 3851 <- 2633) speak for itself, and
initiatives like Autocrypt are just making usability worse;
(b) message classification: the existing schemes do not address the ham
vs. spam divide, leaving it to increasingly compute-intense heuristics; and
(c) the existing schemes do not offer a reliable, automated, actionable
feedback mechanism.
STEPS IN THE PROCESS
====================
* encryption/signature at the MTA instead of the MUA is a major
difference to existing encrypted message schemes; but are nothing new
for encrypted communication schemes, nor for client validation/trust.
Implementing this scheme within tools already doing DKIM signing is trivial.
* work needs to go into defining the added headers to declare the
nature/purpose of the message (sender's MUA/MTA) as a necessary element
to determine economically whether a message is ham or spam. those
headers would need to be sender-signed and not encrypted. Thoughts
still required for headers to prevent replay attacks and other ways to
abuse the system. Input is welcome.
* retrieving two extra files at two well known URLs for each message is
overhead that can scale independently; as is the hosting and
lifecycle-managing of those files.
* more work needs to go into defining the added headers for end-user
feedback collection; and to make the counters tamper-resistant (e.g.
single token per message to avoid double-counting; prevent unauthorized
actioning).
HAM VS. SPAM
============
* spam is in the eyes of the beholder, hence a recipients'
machine-readable policy of what is ham and what is spam, in a well known
location of a web server at the recipient's domain
* JSON or some other efficient and extensible format
* existing tools can be used to manage the lifecycle of
https://example.org:12345/ipp/<alias>.pol already exists and can be recycled
* each individual recipient address' can publish such a policy, which
can be extend, for example to allow messages from known mailing lists to
be sent unencrypted
* it is conceivable that SMTP operators add/modulate/override/merge said
policies with server-wide recipient policies
* work needs to go into formulating the format describing these policies
* the formulation could be inclusive (accept only messages of specific
nature) or exclusive (accept every message except such of specified nature)
* the recipient's SMTP can quickly block with a header check against the
recipient's policy
* the recipient can signal to its mailbox provider when the nature of a
message was misrepresented
* the signal can be used to maintain SMTP client reputation and take
care of offenders with technical penalties
* the signal can also be passed on to SMTP client operator for them to
take care of offenders (their customers!) with monetary penalties
TRUST/SECURITY
==============
* using X.509/PKI allows the recipient, or at least the recipient's MTA
operator, to intentionally decide who to trust and who not; and for what.
* freedom-loving GPG users and other individual self-service operators
won't find creating a self-signed certificate more cumbersome than
generating a GPG key; and the scheme MUST be designed to accommodate
emails that are not sender-declared according to this new scheme;
* hyperscalers with their own CA already generate X.509 certificates at
scale. adding certificate generation/management to their existing
infrastructure is not trivial, but also not particularly cumbersome.
I am thinking this as I go, and I do not have much time -- this is spare
time from my non-tech regular job. Thank you for indulging the ideas.
Yuv
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
