On Fri, Jan 10, 2014 at 11:44:04AM +0100, Patrick Ben Koetter wrote:
> Viktor,
>
> we're lucky to have Carsten Strotmann on our team (here at sys4). You may know
> him for his expertise on DNS. Carsten offered to assist in writing the
> DANE_README.
Thanks. Very much appreciated.
> I'd like you/others to go over the following TOC to make sure we cover all
> necessary aspects:
>
> - What is DANE
>
> - Benefits of using DANE
Since you're documenting DANE for Postfix, I think it is important
in the above two sections to keep the focus on "SMTP Opportunistic
DANE TLS" (even though you also will describe the mandatory
"dane-only" later in the document).
You need to briefly dispel the notion that public CA TLS (aka PKIX,
though PKIX spec also applies to DANE when a trust anchor is used)
is usable without DNSSEC on a large scale for SMTP to MX. It is
not, because with MX indirection the peer name is insecure sans
secure DNS, and since hop-by-hop security is not implied by the
email address, "STARTTLS" is is trivial to downgrade.
DANE for SMTP specifically deals with these problems, and along
the way solves Goedel's problem for CA bundles (any list of
CAs is either inconsistent or incomplete, where inconsistent
means too inclusive to be trustworthy).
Also highlight the need for authentication to be reliable, since
MTAs don't have interactive users to click OK (unlike browsers).
Then add quick-dirty link for client setup and server cert
chain / TLSA RR setup (that will be at the bottom of the
document).
> - Prerequisites
>
> - DNSSEC
> - What is DNSSEC?
> - Why does DANE require DNSSEC?
> - "a bit of a DNSSEC tutorial..."
>
> - Local Resolver
> - DANE will offer only an illusion of security unless the *one and
> only*
> nameserver in /etc/resolv.conf is 127.0.0.1
> - trust-anchor key rotation
>
> - Certificate Considerations
>
> - Pros/Cons of "2 0 1", ...
Right, I only recommend a choice between "2 0 1" and "3 1 1",
everything else is silly (at least for SMTP), but "2 1 1" could be
an option if the TA contains no useful data beyond its key, and is
in fact an intermediate or even root public CA, which might be
re-issued with new expiration dates, ... but an unchanged key.
>
> - TLSA Key rotation
>
> - DANE setup with Postfix
>
> - Building a TLS certificate
>
> - Basic TLS/SSL configuration
> - Basics + refer to TLS_README for tuning, other policies etc.
> - Testing basic TLS functionality
>
> - Configuring DNS-Based Authentication of Named Entities (DANE)
> - Creating a TLSA DNS resource record
> -> tlsagen
> -> Refer to "Pros/Cons of "2 0 1"..."
> - Deploying the TLSA DNS RR
> - Testing the TLSA DNS resource record
> -> posttls-finger
>
> - Enabling DANE support in Postfix SMTP client
> - Params, Options, Policies
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane, dane-only
There are also some DANE related parameters for the
TLS library:
tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
> - Verifying DANE
> - LOG
> - Monitoring
>
> - Troubleshooting
- Quick and Dirty configuration
- Client in brief.
DNS and SMTP agent settings.
tls policy table for exceptions:
- non-dane for emergencies (assuming not an MITM attack).
- dane-only
- Server in brief.
Cert chain.
TLSA RR content.
TLSA RR content during key rotation (of EE or TA cert).
>
> - References
>
>
> Thank you
Thanks again.
--
Viktor.
