Viktor Dukhovni:
> > 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:
Yes, please. something like a minimum level, like we discussed
before I switched jobs (for example, a minimum of 'may', but try
stronger if available).
Wietse
> 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.
>
>
