>> > 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.

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."

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.

Barry

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to