On Jan 1, 2020, at 1:27 PM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
FWIW, Let's Encrypt doesn't currently issue client certificates.
Actually, it does, for example:
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Validity
Not Before: Oct 24 07:01:29 2019 GMT
Not After : Jan 22 07:01:29 2020 GMT
Subject: CN = box.ezemailserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
[...]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
The EKU lists both TLS server and TLS client roles.
And since this would be entirely new practice, it would at least be possible
to require Organization Validation or Extended Validation certificates as a
condition of accepting mail, or more likely, as a condition of not
pessimizing mail... and/or set up email-specific CAs for the purpose of
authenticating SMTP clients.
That's a non-starter. I am not going to pay for EV certs (a dead-end idea
that failed and is going away). There's no scalable mechanism for a third
party to whitelist the good guys. The only thing that can work is for ISPs
to list CIDR blocks that are authorised SMTP relays.
A decade and a half ago, there was:
https://www.ietf.org/archive/id/draft-crocker-csv-csa-00.txt
[ which would IMHO need to be simplified, probably too much baggage in an
effort to reconcile CSV vs. CSA, ... ]
that I was sure stood a much better chance of addressing spam from botnets and
the like than SPF, Sender-ID, DKIM, ... which only touch on the much narrower
issue of "From" forgery in phishing. [ And don't really solve that either, since
naïve users still fall for phishing email that doesn't bother to forge the
message
origin. ] But for various reasons addressing "phishing" got more attention.
Client certs from a CA cannot address botnet spam, but explicit records in DNS
from a domain that stands behind the client's role as an outbound MTA can help,
modulo the same $5/domain that means that makes disposable domains attractive
to the spammer. Which means we'd need technology to blacklist the rogue domains
very quickly (before the spammer earns $5 in revenue by abusing it).
I don't claim that it's simple to make this work - the devil is, as always, in
the details. I don't think there is a magic bullet. But I do see client
cert
authentication of SMTP-over-TLS as another potential tool in the toolbox.
I think they could be useful forensically, and even potentially to show a user
that email arrived along an expected "trusted path", but not for screening out
unauthorised senders. That is sadly not possible.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp