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.
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
- 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", ...
- 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
- Verifying DANE
- LOG
- Monitoring
- Troubleshooting
- References
Thank you
p@rick
* Viktor Dukhovni <[email protected]>:
> On Mon, Jan 06, 2014 at 11:33:26AM +0100, Patrick Ben Koetter wrote:
>
> > > Thus the need for a DANE_README.html, any volunteers? All the
> > > required material is scattered about in:
> > >
> > > http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
> > > http://www.postfix.org/postconf.5.html
> > > http://www.postfix.org/TLS_README.html
> > > http://www.postfix.org/FORWARD_SECRECY_README.html
> >
> > I can work on it this and next week, but my English writing will need some
> > review from a native speaker.
>
> Fantastic. One important point to get accross is that TLS security
> for MTA SMTP to MX is very much unlike TLS security for HTTP or
> even mail client SMTP to static MSA. Even though the TLS protocol
> is the same, the MTA SMTP protocol context is so different, that
> one MUST first shed most of the mental baggage that one may have
> learned from HTTP. For many users the first problem will be letting
> go of pre-conceptions.
>
> The second point, which is critical, is that Postfix DANE will
> offer only an illusion of security unless the ONE AND ONLY nameserver
> in /etc/resolv.conf is 127.0.0.1 (yes, ::1 is also OK). That
> nameserver must implement DNSSEC and be configured with a suitable
> set of trust anchors. At least the correct trust anchor for the
> root zone, plus any additional trust anchors that are stable enough
> to configure locally and important enough to not yield control over
> those domains to the root.
>
> There need to be appropriate mechanisms handle trust-anchor key
> rotation. Some linux packages for unbound come with scripts to
> refresh the root trust anchor, I don't know whether these can
> also handle other trust-anchors in a similar manner.
>
> So there would need to be a bit of a DNSSEC tutorial as well I'm
> afraid. Especially for people who want to operate domains with
> DANE veriable MX hosts. They'll need to understand why (with
> certificate usage 2) wildcard certs are not a very good idea (MITM
> server substitution) and the pros/cons of "2 0 1", "2 1 1", and "3
> 1 1" TLSA records (it makes little sense to use any of the other
> 12 valid combinations, and none to use the 12 with certificate
> usage 0/1).
>
> They'll also need to understand the key rotation and digest algorithm
> agility operational requirements for publishing TLSA records.
>
> The rest, is largely combining the various Postfix docs about DANE
> is a single logical document.
>
> Those are my immediate thoughts that I thought would be helpful to
> get you started, but you'll discover your own ideas as you go along.
>
> -------------
>
> On Mon, Jan 06, 2014 at 05:46:29AM -0800, Corey Quinn wrote:
>
> > I'll handle editing and review if you'd like.
>
> Thanks, that would be great.
>
> --
> Viktor.
--
Patrick Ben Koetter
[email protected]
