On April 4, 2016 at 2:42:15 , Daniel Margolis ([email protected]) wrote:
Thanks for the clarification.
Sounds like a feature to me. Having MUAs do insecure DNS lookups (which is what
they’d probably do) and make misleading assertions about relay security (which
couldn’t be made even if DNSSEC/HTTPS was employed to trust the STS
information, given that forwarding is in the infrastructure and all that). If
you want to have MUAs make assertions, you’re moving in the direction of the
SMTP extension draft, and as Victor pointed out, the infrastructure is going to
ignore even those assertions under some circumstances if that were to deploy.
I am (perhaps parochially) thinking mostly about webmail systems where the MUA
and the sending MTA are mostly the same piece of infrastructure. So my real
goal is for the MTA to be able to tell the MUA at compose time that it has a
policy for the recipient domain and can guarantee certain behavior.
Do you really think an end-user can understand what it means if the MTA will
transport encrypt the next hop of mail relay but can say nothing about relay
hops after that or how the mail is handled by either service provider? Perhaps
I’m missing the motivation for doing this, can you explain why this is useful?
In this context, I think having policies be per-domain is important, but as you
note, you could have a policy semantic which allows a single MX to communicate
a domain-wide policy even with an in-band channel.
> 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.
To clarify a bit the individual steps needed, then, it seems like you're
proposing that given the following stages:
1. Routing information: What MX hostnames are expected
2. Authenticating the MX: Determining that the server TLS cert matches
3. Policy: Ensuring the minimum level of transport-layer encryption
You propose to put #1 in either DNSSEC or HTTPS (with an optimization to use
in-channel in place of HTTPS if the MX domain matches the email domain) and #2
and #3 in the SMTP exchange?
Basically right.
But this doesn't necessarily eliminate the extra DNS or HTTPS lookup (at least
in the case where the MX domain does not match the email domain), right? You
still need to get the routing information somehow, and we're still trying to
make this viable for domains that can't yet deploy DNSSEC. So in that light,
you're proposing that all domains would need at least the SMTP in-band exchange
and that some domains would also need step #1 to be done over HTTPS--meaning
that sending domains would have to still support both options, right?
Presuming there is WG rough consensus that use of HTTPS meets the cost/benefit
cutoff when compared to DNSSEC, then yes that is correct.
I can see the appeal of doing much of this in-band given that it's consistent
with what DEEP proposes, but I'm still concerned that if we need also support
out-of-band, we're just increasing complexity. What do you think?
As long as the only out-of-band is verification of routing information and not
policy, then I don’t see it as increasing complexity. Indeed it’s a somewhat
more conservative approach to architectural cost (trying to minimize use of
extra packets and protocols when performing the core SMTP relay operation).
But I’ll admit I have some experiential bias in that I’ve seen few DNS
additions deploy effectively, and I’ve seen a bunch of SMTP extensions deploy
effectively.
- Chris
On Mon, Apr 4, 2016 at 6:27 AM, Chris Newman <[email protected]> wrote:
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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
