> On Jan 28, 2019, at 7:59 AM, Stefan Bauer <cubew...@googlemail.com> wrote:
>
> But in cases where remote sites do not have published key material, the
> fallback is may with dane, which is a step back in terms of security and not
> wanted.
>
> How can we specify:
>
> 1, Always use at least encrypt
> 2, When TLSA-records are found and valid, use only this to encrypt
> 3, When no TLSA-records are found or the ones found can not be used, fall
> back to encrypt, if not possible, fail.
That requires new code. Sorry about that. The issue is in part
whether a point-fix would be appropriate with a fallback level
when DANE TLSA records are not found, or whether a more general
mechanism should be implemented that can specify more complex
policy:
* dane or else encrypt or else fail
* dane or else verify [match=...] or else fail
* dane or warn and delivery anyway
* ...
In Postfix, when we do something, we tend to skip half measures
and do it "right", i.e. in a general way. So the question is
whether "DANE or else encrypt" is the right design or not.
One can certainly imagine specifying a "minimum" security
level, and then fallback would never use anything weaker.
That would look like:
* dane with hard failure
* dane with warning and fallback to floor level on failure
and silent use of floor level when TLSA not present.
* verify/secure with hard failure
* verify/secure with warning fallback to floor level on failure
and would simpler than a more complex chain of levels with
"on-error" and "not-found" branches. Essentially a little
DSL for a recursive state-machine:
tls_state_machine policy = do
case level policy of
dane
-- Pre-connection policy fallback:
| not-published <- tlsa
-> tls_state_machine encrypt
| unusable <- tlsa
-> tls_state_machine encrypt
-- Post-connection policy fallback:
| auth-failure
-> do
warning
if dnssec-ok
then tls_state_machine verify match=hostname)
else tls_state_machine (verify nexthop:dot-nexthop)
| tls-handshake-failure
-> tempfail
| pre-data-lost-connection -- TLS interop issue?
-> tempfail
| success -- implicit
-> deliver
verify
| auth-failure
-> ...
| tls-handshake-failure
-> ...
| success -- implicit
-> deliver
...
the DSL needs to be usable, not overly complex, and yet cover
the plausibly useful cases. It has not yet been designed...
--
Viktor.
