Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

[Viktor Dukhovni <[e-mail]>]

> On Jan 1, 2020, at 1:27 PM, Keith Moore <[e-mail]> 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.