On 8/3/22 12:14 PM, Jarland Donnell via mailop wrote:
Roger that. So this:
;-)
It's about proper documentation, expectation, and communication. The most secure line is the actual secure line,
I can't agree. I suspect we can agree that security is not binary / black & white.Stock DES was once upon a time the most secure thing. Hindsight shows that it's not /secure/.
the least secure line is the one that says "I am secure" and isn't.
That gets into the philosophical discussion ~> debate of which is the least trust worthy, the thing that says that it's not, or the thing that says it is when it really isn't.
I admit there is a measure of a false sense of security. But that's a perception issue.
From an attacker's point of view, there is effectively no difference in something in plain text and something in ROT13.
This might sound confusing because most people would think "The least secure line is the one that says 'I am not secure'" instead. But when you say "This is not a secure line" you know for sure that both parties fully understand that it isn't secure. Where as if you say "This is a secure line" and it isn't because the other party either doesn't know what they're doing or is the victim of a downgrade attack (through whatever attack vector that came from) then the other party walks away saying "I transmitted secure data" and to them it's over. Playing either role in that situation is bad, but being the intelligent admin who cares none for the other guy is worse than just saying up front: "This isn't secure, plan accordingly."
Monkey in the middle is still a problem on contemporary, supposedly secure, protocols. The monkey can even be outside of the TLS stream. I can configure a mail server to copy messages that were transmitted to & from it via TLS 1.3 with your choice of ciphers.
So ... with that in mind, I feel like your statement about TLS 1.3 is equally as susceptible as TLS 1.0 in that regard.
Then there's still the problem of me using a camera to take a picture of the time limited / self destruct message that was sent using the absolute best security possible. Again, the best channel security falls down with problems at either end.
I feel like you are more in the philosophical domain and pushing back into the technical domain trying to enhance security. I think that's laudable. But I personally don't think ~> believe that "plain text to be more secure than insecure SSL".
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
