Loading...

postfix-devel@postfix.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Postfix new-style TLS policy design Wietse Venema Sun Aug 13 15:21:34 2006

Victor Duchovni:
> On Tue, Mar 21, 2006 at 02:49:16PM -0500, Wietse Venema wrote:
> 
> > I think we're ready for implementation.
> > 
> > As long as the SMTP client maintains a notion of "this is the
> > effective security level", other code can be added later to take
> > advantage of its presence.  I included just enough of that discussion
> > so that we could plan for it now, and avoid painful changes later.
> 
> So onto the implementation discussion:
> 
> There is a minor OpenSSL API obstacle to checking whether an opportunistic
> session is effectively secure. Specifically, the cipherlists in OpenSSL
> are not really designed for after-the-fact "does the session cipher meet
> this constraints of this cipherlist" inquiries.
> 
> Rather the API allows one to set the cipherlist for a context, to list
> the resulting ciphers and to lookup the session cipher id. So we need
> a dummy SSL context (not used for actual connections) to which we apply
> the secure-channel cipherlist so that we can list the resulting ciphers
> and search for the session cipher id on that list.

That would be for opportunistically secure channels only.

> If we don't ancipate changing the main.cf secure cipherlist in the policy
> table (which specifies the required levels, not the opportunistic level),
> we could compute the list of secure ciphers once, and destroy the dummy
> context. If we want to retain maximum flexibility, the dummy context
> may need to be retained.

As long as we can plan for this in the designs, it doesn't need to
be implemented from day one.

What is the issue: run-time cycles or implementor cycles?

> The protocol verification is trivial. The "secure_cert_match" check may
> be somewhat tricky. As we compare the SubjectAlternateNames (or sole CN)
> in the certificate against any "required" patterns, we need to observe
> whether any of those are also "secure" patterns, and keep matching
> until we run out of names and patterns or the effective security level
> is already "secure" (even after the minimum level is met). If there are
> no required patterns, we simply compare against any patterns for the
> (effectively) "secure" level.

If the effective level is needed, I'd match against both the
effective and minimal criteria if they differ. The minimal one may
exceed the secure one!

> Now effective security is just wasted cycles, if we don't do anything
> with it. So perhaps we need a parameter to enable the feature, so that
> sites (most) that don't use it, don't needlessly perform ultimately
> ignored certificate operations:
> 
>     smtp_tls_opportunistic_security = no

Some may want opportunistic TLS without the baggage of certificate
verification, but that seems unlikely. I expect that people will
want to proudly advertise in RECEIVED headers what certificate was
used and whether it could be verified in some way or another.

> And now back to the spec. Do we perhaps want to be able to specify higher
> minimum protocol/cipher attributes for the encrypt and verify levels that
> roll up as default minima for the secure level absent an override?

We have global settings in main.cf for all levels that require TLS,
and per-site overrides in the policy table.

> The motivation is that with "may" we really never want to reject a TLS
> session regardless of how poor the ciphers or protocol may be. That

The global main.cf settings don't apply to the "MAY" security level,
because that level has no security. Remember, we are willing to
send plaintext!!

The main.cf settings specify defaults for the "ENCRYPT" and higher
levels where TLS is mandatory.

The main.cf settings can be overruled with per-site policies.

> Given the total order on the security levels, we could even drop the
> smtp_tls_secure_cipherlist and smtp_tls_secure_protocols, using the
> values from the encrypt level for the encryption attributes, and
> adding only authentication matching at the secure level:
> 
>       smtp_tls_secure_cert_match

The current design has no _secure_cipherlist and _secure_protocols.
We eliminated the need for armies of per-level main.cf attributes.

The current design has global parameters:

    smtp_tls_cipherlist         level >= ENCRYPT
    smtp_tls_protocols          level >= ENCRYPT
    smtp_tls_verify_cert_match  level >= VERIFY
    smtp_tls_secure_cert_match  level >= SECURE

The current design has per-policy attributes:

    cipherlist, protocols, cert_match

We had some discussion about the overloaded cert_match, but that
is now something of the past.

        Wietse