smtp_tls_security_level = dane but have encrypt as fallback

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp_tls_security_level = dane but have encrypt as fallback

Stefan Bauer-2
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_security_level = dane but have encrypt as fallback

Viktor Dukhovni
> On Jan 28, 2019, at 7:59 AM, Stefan Bauer <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_security_level = dane but have encrypt as fallback

Wietse Venema
Viktor Dukhovni:

> > On Jan 28, 2019, at 7:59 AM, Stefan Bauer <[hidden email]> 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.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_security_level = dane but have encrypt as fallback

Wietse Venema
Wietse Venema:

> Viktor Dukhovni:
> > > On Jan 28, 2019, at 7:59 AM, Stefan Bauer <[hidden email]> 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.
> >
> >
>