[Top] [All Lists]

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

2020-01-01 13:01:47
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
            Not Before: Oct 24 07:01:29 2019 GMT
            Not After : Jan 22 07:01:29 2020 GMT
        Subject: CN =
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                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:

   [ 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 
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 
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.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>