From 36bc44599796124358c9580c966af44afe2bc606 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Wed, 26 Aug 2015 11:17:20 -0500 Subject: [PATCH] Fix otr-info construction section Remove unclear opinion from the security section --- inbox/otr-info.xml | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/inbox/otr-info.xml b/inbox/otr-info.xml index 3fcce5f1..544accc5 100644 --- a/inbox/otr-info.xml +++ b/inbox/otr-info.xml @@ -147,14 +147,10 @@

- When sending a message encrypted with OTR, it is RECOMMENDED to encrypt - only the text node of the <body/> element (the message itself). - However, there are some clients in the wild which will encrypt the entire - contents of the <body/> element, including sub-nodes. Because of - this behavior, it is RECOMMENDED that clients decrypt and expand any OTR - messages inside of the body element before re-processing the element as a - whole. Clients that support OTR MUST tolerate encrypted payloads which - expand to XML, and those which expand to plain text messages. + Some clients in the wild have been known to insert XML in the + <body> node of a message. Clients that support OTR should tolerate + encrypted payloads which expand to unescaped XML, and treat it as plain + text.

@@ -270,10 +266,8 @@ xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338 https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > . - This puts generating SHA-1 collisions well within the reach of governments - and well funded criminal organizations. In this authors opinion, there are - no theoretical vulnerabilities, and SHA-1 should be treated with extreme - caution. + This puts generating SHA-1 collisions well within the reach of governments, + malicious organizations, and even well-funded individuals.