[Standards] OX (OpenPGP for XMPP): A new OpenPGP XEP

Georg Lukas georg at op-co.de
Thu Jan 21 16:53:24 UTC 2016


* Sergei Golovan <sgolovan at nes.ru> [2016-01-08 10:49]:
> I don't think any API can tell you in advance that the encrypted message is
> signed inside. Though, probably exposing this information isn't a good idea,
> and you're right about the generic <openpgp/> element as a container.

I think that exposing this information is beneficial to the client, as
it allows to better handle error cases (and indicate them to the user).
I don't think there is a huge data leak beyond what is already seen in
any case (sender, receiver, use of OX, in most cases also message type
and key-ids from the OpenPGP packet metadata).

Personally, I'd go one bold step further and remove all redundancy from
the schema, as redundancy leads to inconsistency, and inconsistency
leads to hard-to-find security issues. We've had those with NUL bytes in
certificate CNs, UTF-8-based directory traversals, and many more.

Therefore I propose the following (controversial) changes:

1. Completely get rid of <signcrypt/>, <sign/>, and <crypt/>.
Store the children directly in the OX message body, or use a generic
child element like e.g. <openpgpcontent/>

Use (or create/adapt) the OpenPGP APIs in a fashion that allows to
derive the sign/crypt flags and timestamp directly from the OpenPGP
message. As it stands now, we are codifying workarounds to
implementation shortcomings into the protocol.

2. Get rid of <time/> for the same reasons as #1. With the current
state, an OX message can have up to three timestamps (XEP-203, OpenPGP
metadata and <time/>). Which one should the client display? Which one is
the authoritative?


OTHER REMARKS

1. 'to' Element:
Initially I was going to suggest also removing the 'to' element, as it
is kind-of-duplicate to the key-id(s) stored in the OpenPGP metadata.
However, as it seems to solve the Surreptitious Forwarding issue of
OpenPGP, it probably needs to stay. §3.2 should be extended however, to
clearly state that only the BARE JID needs to be checked. Furthermore,
the rules for handling MUC/MIX need to be specified. Should the MUC/MIX
JID be stored in the 'to' field, or a list of all participants for whom
this message is encrypted? Should the MUC/MIX JID be allowed as a 'to'
element when verifying an incoming message? If the individual user JIDs
are used, how is a recipient going to distinguish a private message
created for multiple people from a MUC/MIX message?

2. 'from' Element:
I like symmetry, and where there's a 'to' there should be a 'from'. Of
course this is the opposite of the "remove redundancy" idea further
above, and so I would like to see a strong discussion/rationale about
this. I'm not sure yet if "no redundancy" or "symmetry" is the better
approach here.

3. Replay Attacks:
§8.3 claims that Replay Attacks are prevented, without providing actual
details. A combination of to+timestamp does not actually solve this
problem, unless the receiver checks for timestamp increment/change (also
think of out-of-order-delivery). Furthermore, the timestamp only is
guaranteed to have 1-second granularity, so people will probably run
into false replay suppression situations, unless we require the
timestamp to be higher-precision or to be force-incremented for new
(identical) messages. To properly protect against replays, an
auto-incremented sequence number appears more practical.

4. 'rpad' Definition:
The 'rpad' element is awfully underspecced: "The <signcrypt/> and
<crypt/> elements SHOULD furthermore contain a 'rpad' element which text
content is a random-length random-content padding."
As this is a SHOULD, some authors will just ignore the requirement
altogether, or cheat by using a fixed length or fixed content. My
understanding is that OpenPGP automatically compresses the message
before signing/encrypting, so cheating at the above will probably aid
attackers. Nevertheless, I would like to see some strong suggestions for
how to implement this.
Is there really a benefit from having 'rpad' against traffic analysis,
when also having c2s TLS?
When should the 'rpad' element be really used (think of traffic cost on
mobile)?
Should the length of the padding depend on the content length (i.e.
0-20% of the actual content)?
Which distribution should the lengths follow (normal, Poisson, ...)?

5. Public Key Discovery outside of XMPP (key UIDs):
OpenPGP keys have one or multiple UIDs, that are a freeform text[0],
usually containing a name + email address according to RFC2822.
I propose using a more-strictly defined scheme for (auto-generated) OX
keys, e.g.  "User name <xmpp:juliet at example.org>"
While this clashes with an email syntax from the pre-Internet days, it
would allow using external infrastructure (PGP keyservers), as well as
sharing one key between e-mail and XMPP without address conflicts[1],
as well as getting the key signed by other people. Furthermore, it plugs
the under-used RFC 5122.


Georg

[0] http://tools.ietf.org/html/rfc4880#section-5.11
[1] I am aware that this can have other drawbacks, my personal key is
    126KB (in binary encoding).
-- 
|| 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/20160121/23d26993/attachment.sig>


More information about the Standards mailing list