Re: [exim-dev] [hs@schlittermann.de: Re: DANE]

Top Page
Delete this message
Reply to this message
Author: Viktor Dukhovni
Date:  
To: exim-dev
Subject: Re: [exim-dev] [hs@schlittermann.de: Re: DANE]
On Thu, May 08, 2014 at 11:08:03PM +0200, Heiko Schlittermann wrote:

> But ? OTOH, if we always use DNSSEC (and fallback to DNS, remembering
> the answer is untrusted now), we have everything we need for the DANE
> checks, as soon as we see the certificate, haven't we?


Well, you also need to have pre-fetched the TLSA RRs, and configured
the right verification callbacks and associated state, because DANE
chain validation (including name checks) happens during the handshake.

Then once the handshake is complete, you have a boolean verified/
not verified state, on which to base policy, but the work that got
you there, needs to happen earlier.

>     remote_smtps:
>         driver = smtp
>         hosts_require_tls = *
>         tls_require_dane = yes  # defaults to yes
>                                 # but for using DNSSEC it's too late
>                                 # already, because it's done in the
>                                 # routers


Not sure what the "hosts_require_tls = *" means, if it means require
TLS for all destinations, that's rather impractical for the public
Internet.

The Postfix approach is to define TLS security levels:

    - may            Opportunistic unauthenticated TLS
    - encrypt        Mandatory unathenticated TLS
    - dane            Opportunistic DANE TLS
    - dane-only        Mandatory DANE TLS
    - fingerprint        Authentication by leaf fingerprint
    - secure        Authentication via PKIX CAs


Once you choose a level, the semantics of that level are built-in.
The levels come with optional parameters, so a policy table might
be:

    tls_policy:
    # No TLS with example.gov
    example.gov none


    # Leaf fingerprint checks with example.com
    example.com fingerprint match={digest1} match={digest2}


    # Mandatory DANE TLS for example.net
    example.net dane-only


    # Custom trusted CAs for example.org
    example.org secure tafile=/etc/postfix/example.org.pem


    # Custom cipher grade for example.edu
    example.edu encrypt ciphers=high
    ...


If you just complete a handshake and give a user a chain and ask
then to validate everything in a Turing-complete extension language,
they'd have a rather difficult time implementing robust logic for
similar security levels (yes, level is not the best word).

-- 
    Viktor.