On Thu, Oct 31, 2024 at 12:45:25PM +0100, Nick Hilliard wrote:
> > Note that SMTP, as defined here and elsewhere conducts all its traffic
> > in plaintext. Applications which use it that are concerned about the
> > traffic being intercepted or modified SHOULD consider using the STARTTLS
> > extension as described in {{something}}.
{{something}} = RFC3207
> protocol support?
RFC3207 is broadly implemented by MTAs on the public Internet, a few
notable exceptions aside (e.g. tiscali.it). Being able to meaningfully
authenticate the receiving MX host is not generally expected, barring
DANE or its the clunky (and vulnerable to downgrade on first contact)
MTA-STS.
https://datatracker.ietf.org/doc/html/rfc7672#section-1.3
An IANA registry of MTI TLS versions for SMTP STARTTLS may also be
needed, if SMTP is special enough to not be lumped in with general
recommendations for all other "applications". Perhaps something that
the "UTA" WG would have to take up. Presumably, at this point TLS 1.2
is MTI and TLS 1.3 is RECOMMENDED.
What are the expectations around fallback to cleartext should TLS
handshakes fail?
> operational support?
We do have TLSRPT, that could be extended also to vanilla STARTTLS
failure. And there's never a good excuse for failure to implement
self-monitoring.
There are some "Icinga" plugins for monitoring DANE, similar could be
in place for just plain STARTTLS.
As client TLS stacks become more strict over time, one does however need
to keep the monitoring up to date:
- Ensure that EMS (Extended Master Secret) support is monitored for
TLS 1.2, as stacks are starting to require it.
- Ensure that any keyUsage extension in the certificate is
compatible with TLS, some in the wild lack "digitalSignature",
causing interoperability issues.
- ...
For clusters behind a shared load-balancer IP, take time to understand
what it takes to robustly support TLS resumption (no longer quite as
cheap with TLS 1.3 as with TLS 1.2, given always fresh key exchange).
> pki / configuration management support?
With authentication optional, self-signed snake-oil certs are sufficient
and not infrequently used. So not much PKI required, and active
monitoring should detect configuration issues. Though, to be thorough
one might also want to be monitoring from external vantage points.
> In the https world, we've been spoiled by ACME on the server side and
> web browser / operating system updates on the client side.
ACME mostly gets in the way of naïve DANE deployments[1], and is
otherwise not particularly compelling for SMTP. Though given MUAs doing
WebPKI, and operator laziness, the same chain is typically deployed for
SMTP on port 25 as for SUBMIT on 465/587.
--
Viktor.
[1] The majority of observed instances of TLSA records not matching the
live cert chain are with MX hosts using Let's Encrypt, that fail to use
"3 1 1" (SPKI digest) TLSA records and keep the public key fixed across
renewals, or otherwise have good automation to ensure that TLSA record
publication precedes by a few TTLs rollout of corresponding cert chains,
and TLSA RR removal follows retirement of said corresponding certs.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
