Eliot,
Thanks for the detailed comments. Inline...
>>>> In Security Considerations in Section 5, I think it’s probably
>>>> useful to talk about the risk of spoofed messages creating spoofed
>>>> reactions, perhaps a lot of them. What mitigation techniques should
>>>> be employed? One might be to look for a valid
>>>> Authentication-Results header.
>>
>> Security Considerations is an opportunity with infinite
>> possibilities. If anyone wants to supply text to add and others like
>> it, then it should be added...
>>
>
> Here’s what I would suggest:
>
> An attacker may transmit one, several, or many messages that lack any
> form of authentication, indicating one or more reactions, thus causing
> the MUA to mislead the reader into believing a general sentiment to be
> something other than what it is, or that a specific reaction is other
> than what it is. The ultimate appropriate remediation is to
> authenticate the sender of a reaction against a trusted authority.
> Short of that, MUA designers are advised to consider only processing
> reactions that pass a heuristic test as to their likely authenticity.
There are three, considerable problems with your suggestion:
1. In reality, it applies to /any/ content. Reactions are just one
example.
2. You've made the popular assumption and assertion that
authentication reduces deception
3. You made the popular assumption that recipients will be
influenced by signals of authentication.
While I agree with all of these points, I don't think they are responsive to
what Eliot is suggesting. If I read what he said correctly, the MUA would act
on the authentication indicators by not showing the reaction, not with some
broken link indicator or similar. Since this is a reaction indication, not a
message, the issues with false positives are arguably less. Whether they're
enough less, well, that kind of depends on what you use reactions for.
Of course the idea of there being a trusted authority of sufficient
universality that someone could code their MUA to use it is a huge
stretch. And this, I think, is where the proposal falls apart.
As for the idea of using heuristics, the idea of having an open-ended
suggestion that implementors pick something, anything, for this purpose is more
than a little scary given past experience with the things people use as spam
tests. So absent something more specific I don't think this is a good idea.
Although it is intriguing to think about various checks and latching schemes
and so on. But the siren song of a hack in the making is kind of the problem,
isn't it?
Ned
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
