On Sat, Jan 08, 2022 at 03:20:58AM -0500, Viktor Dukhovni
<postfix-us...@dukhovni.org> wrote:
> On Sat, Jan 08, 2022 at 12:00:45PM +1100, raf wrote:
>
> > When reading the documentation on smtp_tls_security_level, I thought
> > dane-falling-back-to-encrypt seemed to be a missing option. But I
> > thought it would never be used as a default, and for any non-default
> > specific remote server, you're likely to know whether they do DANE or
> > not, so you could always pick "dane" or "encrypt" for those.
> >
> > But it would be nice not to have to know whether a
> > known peer has DANE or just TLS. After all, they might
> > change their mind, start with just TLS, and then
> > implement DANE later on.
> >
> > A security level that automatically upgraded from
> > "encrypt" to "dane" when DANE becomes available seems
> > like a good idea.
>
> Perhaps the right insight is that DANE isn't a (local policy) TLS
> security level like the others, rather DANE, when enabled *overrides*
> the local security policy level with "more authoritative" information
> about the TLS capabilities of the nexthop domain.
That sounds like a good way to think of it. Whatever
the policy is, it can't hurt(?) for DANE to apply when
available, as long as the conditions are right for
Postfix to be able to support DANE (i.e., a validating
local resolver).
> I can then refactor DANE, not as a security-level, but rather as a
> feature you can enable or disable either globally or per-destination.
>
> main.cf:
> smtp_tls_dane_enable = yes
>
> tls_policy:
> example.org encrypt dane-enable=yes
> example.com secure match=.example.com dane-enable=no
If "smtp_tls_dane_enable = yes" is in main.cf, I would
think that should mean that the "dane_enable=yes" above
would be redundant, but perhaps useful in the absence
of "smtp_tls_dane_enable = yes". But I think having a
global parameter stating that DANE support is available
is better than *only* a site-specific policy parameter.
I think it would make config file comprehension easier
(i.e. important information like telling Postfix that
it can implement DANE support should be in main.cf
rather than a separate tls_policy file - and it only
needs to be stated once - but maybe that's just a style
preference).
When would "dane-enable=no" be needed? If TLSA records
are present and usable (even when verifying the
certificate chain), is it right to ignore them (if
Postfix is configured to enable DANE)? I suppose any
feature that can't be turned off is a bug. When you
know there is no DANE, you can save time by not looking
for TLSA records.
> The "dane-only" level remains a true local policy partly supplemented
> with remote detail, but the "dane" security level becomes a legacy
> setting.
>
> The question is then what to do about backwards compatibility for all
> the users who have "smtp_tls_security_level = dane"? We would likely
> need a second parameter to indicate the real security level when this is
> the case. Something like:
>
> main.cf:
> smtp_tls_local_security_level = may | encrypt | ...
>
> tls-policy:
> example.org dane local_level=secure match=.example.org
>
> which would then make for two ways to configure the same result, and so
> perhaps, to keep things simpler, accept the fact that the interface is
> not without a history, however imperfect, and pretend that "dane" is a
> fully-fledged security level, but under the covers use
> "smtp_tls_local_security_level" as the true underlying policy.
I think smaller changes to the config language are
preferable, except when more complex changes enable much
greater flexibility (that will be used). Having
"smtp_tls_security_level = dane" and either
"smtp_tls_local_security_level = may" (the default) or
"smtp_tls_local_security_level = encrypt" seems simple,
and would satisfy the needs of the original poster.
[But see below where I think I understand the above better]
One thing that puzzles me: if "smtp_tls_security_level = dane"
becomes a legacy setting, and "smtp_tls_dane_enable = yes"
becomes the new thing, what would the new replacement for
"smtp_tls_security_level = dane" look like exactly?
Would it make sense for the replacement version of:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
to be:
smtp_dns_support_level = dnssec
smtp_tls_dane_enable = yes
smtp_tls_security_level = may
or:
smtp_dns_support_level = dnssec
smtp_tls_dane_enable = yes
smtp_tls_security_level = encrypt
depending on what you want the default to be in the
absence of DANE?
That seems simple enough. I think I don't understand
the meaning of "smtp_tls_local_security_level" in
addition to "smtp_tls_security_level". But I'm only
thinking about this in terms of main.cf where you only
have a single policy for all remote servers. I'm a bit
lost with the per-site TLS policy settings.
I think I get it. smtp_tls_security_level = may-or-encrypt
is the *default* default for sites that *don't* have a
per-site policy, and smtp_tls_local_security_level = may-or-encrypt
is the default for sites that *do* have a per-site policy.
If that's right, then the example above:
> tls-policy:
> example.org dane local_level=secure match=.example.org
should probably be different. Since this is about backwards
compatibility for "dane", the idea of adding "local_level=secure"
and leaving "dane" in place seems wrong. If a per-site policy that
uses "dane" is going to be changed at all, it makes more sense to
just change "dane" to "secure" and rely on DANE support being there
if it has been implemented for the remote server. i.e.:
main.cf:
smtp_tls_dane_enable = yes
tls-policy:
example.org secure match=.example.org
with the backwards-compatible version being:
main.cf:
smtp_tls_dane_enable = yes
smtp_tls_local_security_level = may (default)
tls-policy:
example.org dane match=.example.org
But your version does allow more ways to express the
intention, and that's not a bad thing, and it allows
people to keep using the "dane" term but changing what
it means.
> Either way, it becomes possible to honour RFC 8461 and prefer DANE to
> MTA-STS when both are available, if the dynamic MTA-STS policy add-on
> table returns "dane" and a local MTA-STS policy in case DANE is absent.
I won't pretend to understand how it achieves that :-)
but that sounds like a nice added benefit to get out of
this. Hopefully, a concrete example can be added to
postfix-mta-sts-resolver's documentation.
> Turning "dane" into a non-level is cleaner in principle, but it may be
> too late to completely change the design.
Software gets tricky like that. I'm sure it can work out OK
either way.
> --
> Viktor.
cheers,
raf
