On 13/01/2013 19:22, Viktor Dukhovni wrote: [..] It is true that TLS/SMTP is often used but rarely discussed while making new SMTP/TLS RFCs. Most stuff is written with https and browsers in mind. There is a RFC-draft for S/MIME TLSA though:
http://tools.ietf.org/html/draft-hoffman-dane-smime-00 > In any case, I propose that we add support for root CA fingerprint > matching to the Postfix TLS engine allowing verification of trust > chains that contain a matching, possibly not a-priori trusted, root. > > With this it becomes possible to map the results of a DANE DNS lookup > to a Postfix TLS policy. The rest is just additional glue to compute > such a policy on the fly when appropriate DNS APIs are broadly available, > and corresponding records are obtained via DNSSEC. That sound like an good idea. > Concretely, to support DANE, we need two additional attributes in > the policy table, one to override the smtp_tls_fingerprint_digest, > so as to support <https://tools.ietf.org/html/rfc6698#section-2.1.3> > and another to specify the root CA fingerprint (which is computed > from the full certificate is that is provided in DNS). ok. > So when a CA is involved (certificate usage 0 or 2) the imputed > TLS policy would be: > > example.com secure \ > digest=sha-256 \ > rootca=<some-fingerprint> \ > rootca=<another-fingerprint> ... \ > match=<already-supported-match-syntax> > > and when a CA is not involved (certificate usage 1 or 3) the imputed > TLS policy would be: > > example.com fingerprint \ > digest=sha-256 \ > match=<fingerprint> \ > match=<another-fingerprint> ... that would be computed parameters? or fixed configuration (just to understand the example correctly) ? > The DANE specification potentially supports mixed security models, > wherein some of the elements of a TLSA RRset specify usage 0 or 2, > and others usage 1 or 3. This is not easily accomodated by Postfix > at this time, since the TLS library supports exactly one of the > two security models for a given connection. Maybe the client could signal the security model/use case within the TLS handshake? Like an extension to STARTTLS (or even STARTTLSA but that would be messy). Just brain storming here.. > I would be inclined to ignore usage 0 and 2, when 1 or 3 is present, > since given the expected peer certificate, there is no need for > any CAs. Yeah. Currently we just look if any client cert is given. It would be actually an improvement if we could at least verify that it is associated with the given DNS records. > Comments? You are right that DNSSEC is not wide spread enough (client wise and general acceptance, and thereof TLSA would need time to grow, too). But I think if you give a good reason why you actually want to use it, like to make TLS or authentication with SMP more trustworthy (even with some minor flaws), that would motivate people to implement it. It is the old chicken and egg problem. TLS with diginotar like CAs is broken already, maybe TLSA could provide a solution which "sucks less"... Greetings, Stefan
