[Standards] Proposed XMPP Extension: OpenPGP for XMPP
flo at geekplace.eu
Wed Apr 13 11:27:13 UTC 2016
On 13.04.2016 12:23, Georg Lukas wrote:
> * XMPP Extensions Editor <editor at xmpp.org> [2016-04-12 16:18]:
>> Title: OpenPGP for XMPP
Hi Georg, thanks for your feedback.
> 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.
I get your point, but don't draw the same conclusion. One could also
argue that there will be implementations that fail to verify that the
message is signed and encrypted in the IM case. Or that fail to perform
any other verification required by OX.
I repeat myself, but I happily say it again: I view the current design
decision as advantageous over having a single tag for the OpenPGP
content element. As you say, client authors are lazy and maybe do not
read the OpenPGP API libray's documentation carefully writing incorrect
code when using the library's API: One such author may write:
String payload = <data>SECRET_DATA</data>
String signcrypt = <signcrypt><to ...>... + payload + </signcrypt>
byte pgpMessage = openpgp_api_encrypt(signcrypt)
String openpgpElement = <openpgp> + base64(pgpMessage) + </openpg>
I would suspect that the authors intention was to sign and encrypt the
data. But what if that's not what's happening in openpgp_api_encrypt()?
If there is only a single OpenPGP content element, as you suggest, then
it would *not* be obvious that something went wrong.
> 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!).
Then how would the client determine and verify the senders key? If the
client expects <signcrypt/> then he also expects the senders signature.
> 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).
The only thing implementations additionally need to do is to check the
element name, after processing the OpenPGP message, if it matches the
modus. A little bit of extra effort for a huge gain.
But since IMHO both approaches have their advantages and disadvantages,
it is only a matter of what you think the better trade-off is. Let's
hear what others think.
> 2. The timestamp is insufficient for replay mitigation.
Are you confusing mitigation with prevention? The only way to have
replay attack prevention is by using a counter based mechanism, which
would add an extreme amount of complexity to the XEP. That is why replay
prevention is not in the scope of OX. I think the timestamp provides at
least some mitigation against replay attacks.
> 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.
I don't see an issue here in the IM case, i.e. human-to-human
interaction. If a different use case, e.g. M2M, requires replay
prevention, then it needs to ensure it by other means. Again, replay
prevention is not in the scope of OX. It may be provided by an future XEP.
> 3. The 'rpad' element is underspecified.
I think it is sufficiently specified (for now): random-length,
random-pad. But I'm happy to hear your suggestions how you think this
could be improved. So far, you gave none. We could also extend OX's rpad
specification after we have gained some experience from the
implementation. That's why the next state of OX is 'Experimental' and
not 'Final'. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards