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.

Reply via email to