On 2/28/19 8:01 AM, Barry Leiba wrote: >>>> To elaborate on one point a bit: it seems to me that it's harmful to >>>> security to allow the sender to unilaterally override the recipient's >>>> preferences that something be encrypted. To forestall one argument, >>>> yes, the sender knows the contents of the message, but the recipient >>>> knows their own circumstances, and they may be at particular risk >>> The general approach of REQUIRETLS is that the sender is in a good >>> position to determine the sensitivity of the message(s) they are >>> sending, because they know what the message is. >> Right, this is what I am disputing. > I have to agree with EKR about it not completely being the sender's > decision, though for a rather different reason. I really doubt that > in the vast majority of cases any human user will actively choose or > not choose this option on a message-by-message basis. I think that in > the real world we'll see one of two use cases: > > 1. The sending system is just configured to require TLS, because, of > course, it's a Good Thing to make sure TLS is used all the time. This > might or might not cause frustrating delivery problems, depending upon > how broadly and quickly this gets deployed.
FWIW, I read EKR's comment differently, that he was concerned about overriding the recipient domain's preference that TLS be used with the RequireTLS: no (or perhaps TLS-Required: no) header field. From his followup message just received, it sounds like that's the case. WRT your concern above, I expect that problem to be self-correcting. Sending systems that are configured in this way will learn quickly about the delivery problems, and correct what is arguably a misconfiguration of their mail systems. We can't design protocols so that they are free from the possibility of misconfiguration. > > 2. Some other aspect of a message, such as having it marked "Company > Confidential", "Top Secret", or some such, will result in the sending > system requiring TLS for that message. My experience with working in > organizations that use such markings is that they overuse them: the > sending human doesn't actually determine the sensitivity; rather, the > sending human becomes used to putting "Top Secret" on nearly > everything, or "Confidential and Privileged", in the case of lawyers, > on absolutely everything including, "Let's have lunch." Sure, people overclassify stuff all the time. If that isn't working for people, they won't use those markings to key the use of REQUIRETLS, but will instead discover what domains they ought to be able to communicate with via TLS, and use it for those domains. > > For EKR's concern about the recipient's preference, this protocol > would need some sort of recipient policy that senders would look up. > While I absolutely see the value in that, I'm not sure how workable it > would be. Isn't that recipient policy MTA-STS or DANE? -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
