Re: [Uta] New proposal: SMTP Strict Transport Security

[Viktor Dukhovni <[e-mail]>]

On Mon, Apr 11, 2016 at 10:07:14AM +0200, Daniel Margolis wrote:

> I see your point. But I think one thing still needs to be specified. In the
> smarthost case, what domain is used to validate the server certificate
> during the HTTPS policy fetch?

The nexthop domain.  It may, or may not, be subject to further MX
indirection depending on local policy:

    1.  # Forward example.com email via example.net's MX hosts
	# whatever they may be
	#
	example.com	smtp:example.net

    2.  # Forward example.name email via the smtp.example.org
	# relay host.
	#
	example.name	smtp:[smtp.example.org]

In case "1" the STS policy DNS lookup (signal of support) would be
at "example.net" and the well-known URI would be https://example.com/...

In case "2" the STS policy DNS lookup would at "smtp.example.org",
and if that happens to indicate STS support, the well known URI
would be https://smtp.example.org/...


> Presumably it's now the domain of the
> smarthost, not the domain of the recipient domain (for obvious reasons).

Yes, always the domain of the SMTP nexthop, which may or not be
subject to further MX indirection, but recall that (RFC 5321) relay
hosts are just (implicitly) MX domains with:

	smtp.example.com. IN MX 0 smtp.example.com

So the two cases are the same, the STS policy is always associated
with the owner-domain domain on the (possibly implicit) MX RRset.

> But this is mildly funny; absent smarthosting, it's the email domain that
> signs the policy (for obvious reasons); with smarthosting, it's the MX
> domain?

Nothing funny at all, and not it is always the transport nexthop
domain that signs the policy.  Do not confuse the nexthop domain
with its MX exchange host, even when they are necessarily the same
(example 2).

> I guess this is why Chris was saying it makes sense to separate routing
> policy and security policy, but I don't love the complexity that that adds.

Yes, these are related.  With DANE routing is protected by DNSSEC
alone, and TLSA records then provide security policy for the target
MX.  Since TLSA records are cleanly separated from routing they
protect the traffic for that MX regardless of whether MX indirection
was used or not.

In Postfix 3.1 (released in Feb 2016) we by default also make use
of DANE TLSA records even when the MX RRset is not signed, provided
the MX host's TLSA records are.  We don't log that as being as
secure as having signed MX RRs, but it does protect against active
attacks when the DNS records are not compromised.

> I think instead it makes sense to simply say that in the smarthosting case
> the policy domain is the smarthost domain.

Not sure where "instead" comes from, that's the only plausible
interpretation for transport security, but note that when the
nexthop domain (smarthost is a special case of nexthop based on
local policy) is subject to further MX lookups (example 1), the
STS policy is associated with the nexthop domain, not the target
MX hosts.

-- 
	Viktor.