On Thu, 27 May 2021 13:07:39 -0400, Viktor Dukhovni wrote:- >On Thu, May 27, 2021 at 05:42:34PM +0100, Matthew Richardson wrote: > >> and I am wanting to enhance this for certain specific domains to >> require mandatory encryption, without neutering DANE if present. >> Thus, the suggestion of an additional "dane-or-encrypt" level seems >> like a very good idea! > >Presumably, in practice you'd use that only for specific destinations >via the policy table, rather than globally.
Yes - correct - using "smtp_tls_policy_maps", or any other better way. >The barrier to progress is deciding whether a point solution such as >a new level like "dane-or-encrypt" is good enough, or whether the right >way forward is a more general syntax for specifying what happends when >a dynamic level like dane finds its preconditions missing. > >A more complete set of options might be: > > * "dane", or else "encrypt" > > * "dane", or else "secure" (equivalently "verify" with explicit > "match" patterns). > > * "dane", or else "mta-sts" (built-in "mta-sts" is not presently > supported or even planned, but perhaps some day...) > > * "dane", with an "on fail" override to deliver anyway, but the > possible MiTM is logged and is "tamper-evident". (This > should/would be discouraged, except as a limited-duration > work-around). > > * "mta-sts", or ... (again if some day implemented) > >which requires some design. > >If a "dane-or-encrypt" feature is implemented it would have to be >supported for a long time, and would need to have a clean mapping onto >the long-term approach, allowing its implementation to be subsumed by >any later more general solution. So some care is required in deciding >the path forward. I would agree that this does require some care/consideration in the design. Indeed, I had not spotted that some of the other higher security options would also disable DANE. It looks as if the existing options for "smtp_tls_policy_maps" lack flexibility to work well with DANE. Certainly, having to disable DANE checking to force encryption is not a good thing! :-( If it helps (it may not!), another way to look at this is wanting to say "no plaintext" on certain outgoing SMTP traffic. This seems to be analagous to the "reject_plaintext_session" which one can use as within "check_sender_access" in "smtpd_recipient_restrictions" to control incomming SMTP traffic. Personally I think "dane-or-encrypt" is good enough (but I am biased because that is what I am trying to get working!). If this could be done, without prejudicing being able to do the other options later, that would be ideal. Best wishes, Matthew
