On April 1, 2016 at 19:18:31 , Viktor Dukhovni ([email protected]) wrote:
On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote:
> I feel very strongly that policy for SMTP relay should be advertised by
> SMTP and protected by SMTP TLS. Doing anything else creates a much larger
> attack surface on the policy information and is both more complex and less
> secure. The preferred mechanism to sign SMTP relay routing (DNS MX) is
> DNSSEC. I'm open to proposals for alternate mechanisms to sign MX record
> information due to the difficulty of deploying DNSSEC, but such mechanisms
> should not be confused with security policy.
Unfortunately, in MTA-to-MTA SMTP, the receiving SMTP server has
no idea what domain the sending SMTP client wants to deliver mail
to at the time that it advertises its ESMTP extensions in the EHLO
response.
This correctly identifies a key difference between SMTP relay and SMTP
submission. I had missed this, thank you for raising it!
For SMTP submission, there’s an early-indication of domain ownership from the
mandatory user authentication (multi-domain hosting services tend to use email
address as user name to get this benefit). For SMTP relay we have no mechanism
to indicate the intended domain so to handle the case of a multi-domain hosting
service that offers different policies for different domains we’d need to add a
way to communicate intended domain early. This can be done with an SMTP verb
(adding a round trip) or by using TLS ALPN or something similar (no new round
trip).
For this (and other related) reasons, in-band SMTP security policy
can only be communicated for the given SMTP server, and not the
recipient domain.
I’m not convinced this is true. I’d like to hear those other reasons.
A relay MTA MUST NOT make any conclusions about recipient domain
security based on security policy advertised by a particular MX
host. An individual MX host cannot advertise security policy
(implicitly) for every single domain it happens to receive mail
for, except for future relaying via that *same* MX host.
If the MX-from-DNS isn’t trusted, then no policy can be trusted. But
STS-from-DNS has the same issue.
To secure SMTP relay traffic to a recipient domain, the routing
needs to be secured by some means. STS (with sensible modifications)
proposes doing so via an HTTPS well-known URI associated with the
recipient domain. This is achieved via DNS-based signalling of
the existence of the STS well-known URI, and likely DNS-based
signalling that a cached policy is stale and should be refreshed.
Your suggestion, in that light, should be interpreted to say that
the STS URI should be used to only secure the routing information
(security for MX records via HTTPS rather than DNSSEC), and that
once the routing information is secured, security policy for the
given relay be in-band via SMTP and modeled on DEEP.
Mostly yes. I’d also want to consider an optimization to skip the HTTPS step
for self-hosted domains just to reduce overall new traffic.
Note that consequently, a domain would be able to downgrade to a
non-TLS provider, by serving a routing-only policy that references
new MX hosts that don't support a new relay-MTA flavour of DEEP.
We decide in the specification whether the policy attaches to the domain or the
SMTP hostname. This is a design choice.
Also, when a sending relay sees new MX RRs incompatible with a
cached routing policy, it would be able to refresh that policy,
(provided the well-known STS URI is still up and running) and
deliver via the subset of MX hosts that match the refreshed policy.
This all follows from a conclusion I don’t agree with.
[ MX hosts that don't match the policy MUST NOT be ignored when
doing relay loop elimination. They would have to be treated
as though connections to them are failing, not as though they
weren't part of the MX RRset. ]
Once policy is latched for a domain, any SMTP relay not complying with the
policy is a failure. We’ll want to make sure we get the 4xx vs. 5xx rules right
in the spec for this.
- Chris
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
