On Wed, Aug 26, 2015 at 07:32:58PM -0700, Alice Wonder wrote: > LSA record was not usable, I have been confused, because that conformed to > the DANE / TLSA RFC.
The DANE TLSA RFC has a pending update in the form of draft-ietf-dane-ops which is sitting in the RFC editor queue for imminent publication. That document updates RFC 6698 to clarify that only DANE-TA(2) and DANE-EE(3) are suitable for opportunistic uses of DANE. This is further amplified in the MTA-to-MTA SMTP DANE specification also in the RFC editor queue. > I suggested that maybe SMTP servers, which are only doing hostname > validation and can't be expected to CA validate, should treat a 1 x x as a 3 > x x and was basically shot down for suggesting that. That ad-hoc mapping is not required of clients, and IIRC Exim treats usages 0 and 1 as "unusable". The Postfix DANE implementation was developed concurrently with the SMTP draft, and predates the WG consensus to not encourage clients to re-interpret the TLSA records published by servers. > But now reading the Postfix documentation that seems to be exactly what it > suggests: > > http://www.postfix.org/TLS_README.html#client_tls_dane This is not a "suggestion", it is documentation of current Postfix behaviour. > I have since changed my _25._tcp tlsa record to use > > 3 0 1 hash > > But now reading the postfix documentation it seems that isn't necessary. > > Is it necessary or isn't? For port 25 SMTP, to enable DANE, you MUST publish records with usage DANE-TA(2) or DANE-EE(3). > I like things KISS and DANE seems to no longer be KISS with TLSA record > specification varying dependent upon the port. The specification does not vary by port. The meaning of the various record types remains unchanged. Not all record types are suitable for all applications. The DANE update draft (draft-ietf-dane-ops) recommends that the multitude of choices is pointless, and most cases just two are quire sufficient: _port._proto.server.example. IN TLSA 3 1 1 <ee-spki-sha2-256-hash> _port._proto.server.example. IN TLSA 2 0 1 <ta-cert-sha2-256-hash> Until some future application protocol specifies that only the PKIX-TA(0) and PKIX-EE(1) usages are appropriate for DANE with that protocol, the PKIX usages offer no additional security and just make DANE less reliable. Therefore, it is best to avoid these. I think they were defined as a political expediency rather than out of real necessity. And politics aside, might never have been defined at all. > And now it seems the Postfix docs are in contrast with the draft. There is no conflict. Postfix supports an ad-hoc mapping that is not standardized by the draft. We may yet remove that mapping in the future. There are just two domains with PKIX-EE(1) TLSA records in my survey, and ~1930 with usages 2 or 3. The actual number of domains with usage 3 is MUCH higher, because domains with MX hosts at some provider MX hosts (with DANE-EE(3) TLSA RRs) are drastically under-represented in my automated scans. > Thank you to anyone who can help me understand what is really going on. Postfix implements a PKIX-EE(1) to DANE-EE(3) mapping that is ad-hoc and not standardized by any IETF document. That mapping has been mostly harmless, but should perhaps be withdrawn in a future release. The mapping predates the finalization of the corresponding text in the MTA-to-MTA DANE draft. Given that dearth of domains publishing PKIX-EE(1) there's really little point in bending the rules to support a negligible fraction of outliers. Furthermore, support for 3->1 mappings might lead users to erroneously expect 0->2 mappings, but the latter are in fact problematic. So supporting neither of the potential mappings is simpler and cleaner. -- Viktor.
