Wietse Venema: > 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).
Or a sequence of acceptable levels. > 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. > > > > >
