We had a bunch more discussion on this on the IESG call. It seems like the primary use case for TLS-Required=no may be to exempt what's basically the control channel from the requirement to use TLS. So, for instance, I am getting persistent bounces from you and I want to notify you about it, so I send that notification with the TLS-Required=no flag set [0].
Assuming that's right, then ISTM that actually this is not the ideal design, both because it's not clear how the flag gets set and because the recipient has had no chance to weigh in. What I would suggest would instead be to extend MTA-STS and DANE to exempt specific "control" addresses (e.g., Postmaster) from mandatory TLS. This seems like it would solve the main problem while avoiding opening the can of users just marking routine messages as non-sensitive. -Ekr [0] In some unspecified way? Perhaps a button in the MUA UI? On Wed, Mar 13, 2019 at 2:55 PM Eric Rescorla <[email protected]> wrote: > > > On Wed, Mar 13, 2019 at 2:49 PM Viktor Dukhovni <[email protected]> > wrote: > >> > On Mar 13, 2019, at 5:13 PM, Eric Rescorla <[email protected]> wrote: >> > >> > Well, I think this field should only override the outgoing and not >> incoming policies (or be removed). >> >> To be clear, let's imagine a company (say a bank) with the following TLS >> policies (written roughly Postfix-style, but should be clear even to the >> uninitiated): >> >> # Mandatory PKIX authenticated TLS with back office settlement >> business partner, >> # And mutually agreed set of CAs. >> # >> partner.example secure tafile=partner-cas.pem >> match=mx.partner.example >> >> # Mandatory DANE-TLS with another business partner known to >> support DANE >> # >> partner2.example dane-only >> >> # Opportunistic DANE TLS when available with general-purpose email >> # (In real life the global default would be specified elsewhere) >> * dane >> >> I think you're saying that the company could allow its users to bypass >> the locally-policy business partner domain rules, but must refuse to >> allow users to exempt casual correspondence from DANE (or MTA-STS) >> policy when published by the destination domain. >> >> Is that right? >> > > Yes. > > -Ekr > > >> -- >> -- >> Viktor. >> >>
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
