Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

[Viktor Dukhovni <[e-mail]>]

On Wed, Apr 13, 2016 at 10:43:31AM -0700, Chris Newman wrote:

> DANE is merely one method of validating a certificate, there can also be
> SMTP policy orthogonal to DANE.

Sure, but I don't see DEEP-style policy latches playing much of a
role, if any, in MTA-to-MTA opportunistic transport security.  No
plans to implement.  Sorry about that.

> Take for example, DEEP's 'tls11' and 'tls12' directives. Those specify a
> minimum acceptable version of TLS for future connections.

I don't see adding any support for this in Postfix.  Keep in mind
that MTA-to-MTA TLS is still opportunistic security even with DANE.
The client cannot be expected to jump through excessive hoops for
marginal gain.

Caching of TLS policy pins for every MX host ever contacted is not
a sensible requirement on the sending MTA.  Nor does this achieve
broad security, since secondary/tertiarry/... MX hosts are rarely
contacted, and MITM attackers can often block access to these, and
cause connections to use MX hosts that have not been used recently.
Caches with no size or TTL constraints are not viable.

The higher we set the bar for use of opportunistic TLS the less
useful it becomes.  We need to be reasonably modest in our goals,
so that they remain broadly achievable.

> So the question is where to put SMTP relay security policy
> that is orthogonal to DANE.

Opportunistic transport security for relays needs to avoid being
overly-prescriptive or require significant sender resources.

> Seems like wherever we choose to put the policy for SMTP relay STS (whether
> in a DNSSEC-protected DNS record, HTTPS well-known or SMTP+STARTTLS),
> that's where we should always look for SMTP relay policy.

DEEP is a fine hammer for MUAs, let's not make every SMTP-related
problem a DEEP nail.

DANE SMTP is deliberately minimally prescriptive.  The "floor"
security policy on acceptable ciphers and protocols will gradually
rise via adjustments to local policy and MTA software defaults as
older protocols and ciphers become increasingly rare.  Keeping the
design as simple as possible is a key feature.

If STS is to be a successful (be it perhaps in some sense secondary)
alternative it too needs to remain (or become) sufficiently simple.

Transparent interoperability is more important than dialing security
up to 11.

-- 
	Viktor.