[Standards] Proposed XMPP Extension: OpenPGP for XMPP

Georg Lukas georg at op-co.de
Wed Apr 13 10:23:49 UTC 2016


* XMPP Extensions Editor <editor at xmpp.org> [2016-04-12 16:18]:
> Title: OpenPGP for XMPP

I see multiple security problems in this XEP (which I addressed
on this list[0] and in private conversations with the authors, where I
unfortunately failed to convince them):

1. The XML element embedded in the OpenPGP message ('sign'/'signcrypt'
/'crypt') may contradict the OpenPGP message type. Redundancy is the
first step to inconsistency, and client authors are lazy. There will be
an implementation sooner or later that fails to check *both* fields.
Such a client could be susceptible to message forgery attacks where a
'signcrypt' body is embedded in an unsigned but encrypted OpenPGP
message (everybody can encrypt to your public key!). Having this element
makes the XEP and implementations unnecessarily complex (now we have
nine potential cases instead of three, and six of them are corner cases
only created by attackers).

2. The timestamp is insufficient for replay mitigation. The default
granularity is 1 second, so it is possible for multiple legitimate
identical messages to share a timestamp (imagine somebody typing "OK"
twice after each other, or machine-to-machine communications/IoT). The
'rpad' element can achieve that, but then it must be advertised as such
and stored in the receiver's replay detector.

3. The 'rpad' element is underspecified. The problem it is supposed to
address ("The 'rpad' element of the OpenPGP content elements exists to
prevent length-base side channel attacks.") is only vaguely described
and understood. A client implementor reading the XEP will not know _how_
to actually mitigate the attack vector, and probably either ignore the
element altogether or provide an insufficient implementation. I don't
consider this XEP to be the ultimate place to define how a random
padding is to be designed. Still, as a client author I can't see how to
fulfill this requirement of the XEP. IMHO, the necessity and properties
of this element need some proper discussion before going on.


Georg

[0] http://mail.jabber.org/pipermail/standards/2016-January/030853.html

-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160413/213b0900/attachment-0001.sig>


More information about the Standards mailing list