Source: libotr
Version: 3.2.1-1
Severity: important
X-Debbugs-Cc: security@???, anarcat@???, tails-dev@???
Control: tag -1 + security
Control: found -1 3.2.0-2+squeeze1
Hi,
as you are surely aware of, it's been known [1] since 2006 that
clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject
to protocol downgrade attacks clients. It's also been known for
a while that OTRv1 has serious security issues (that were the main
reason for a v2, actually). In short, support v2 only is the only safe
way to go these days.
[1]
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945
It took a while to obsolete older v1-only software, and another while
to complete the libotr 4.x transition and get to a sane state in
Debian testing. Now, I think the time has come when we can reasonably
expect v2-only to work for everyone.
I think that the only reasonable course of action from now on is to
patch libotr in stable and oldstable to only support OTR v1.
Thoughts?
JFTR, libotr 4.x (testing/sid) is not affected by these issues (fixed
in upstream commit 7ffba65f).
(The only alternative I can think of would be to remove it from
stable, remove all reverse-deps that are useless without OTR support
(e.g. pidgin-otr), patch all reverse-deps that are useful without OTR
support (e.g. kopete) to drop it, and prepare tons of backports.
This requires tons of work, coordination with many package
maintainers, and approval from the release team. I don't think we want
to go this way.)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
