XSF Discussion - 2016-01-21

Flow, what’s the rationale for having moved everything out of signcrypt, in OX?

Link Mauve: please define "everything" :)

Err, not out, more like moved the attributes to elements.

ahh I assumed that is what you meant

short answer: because you can't have multiple attributes with the same name

And you want to, in this case?

and we want to be able to specify multiple recipients

so the initial idea was to <signcrypt to='foo@bar.com' to='baz@bar.com'>

but that's not valid xml

so now we have <signcrypt ...><to .../><to .../>...

Oh, the <to/> are there to list every recipient that can decrypt?

Link Mauve: Yes "OpenPGP content elements MUST possess at least one 'to' ..." and "The 'to' element(s) MUST have a 'jid' attribute which contains the intended recipient's XMPP address..."

s/recipient's/recipients'/ then.

RFC 4880 already allows multiple recipients and there is no reasion to restrict an OX OpenPGP content element to one

So should there always be a <to/> for yourself?

Always?

Link Mauve: I don't think so

The encrypt to self is to allow users to read their own send messages

The <to/> in OpenPGP content elements is there to prevent attacks where the message is send by an attacker to a third party

which was not the intended recipient in the first place

It might be useful to define what to do if you (the recipient) don’t match any of the <to/>.

Link Mauve: I think what we have in OX § 3.2 is sufficient right now

You can't specify what an implementation should to if the verification fails

If I wouild ask you what you plan to do in profanity, and then I would ask daniel what he plans to do in conversations, I would likely get two different answers.

poezio* :)

Actually, just slixmpp for now.

Link Mauve: Uhh, sorry.

Isn't the profanity dev also here?

I know the mcabber dev is here, coucou McKael.

Also the primitivus dev is here, coucou goffi.

Link Mauve: Are you going to the Summit/FOSDEM?

Sure. :)

Will miss the first morning of Summit though. :(

I need to check this OX stuff, it can be interesting for our private blog feature

afaik the profanity dev is boothj5, and he’s not here

am I reading OX right, that the <openpgp> element contains base64-encoded xml elements?

Ge0rG: no base64 encoded RFC 4880 messages which contain an encrypted and/or signed UTF-8 string which contains XML.

bbl

maybe section 3 should more clearly state that, and provide a rationale

a rationale for?

a rationale for putting base64-encoded xml into xml.

But that's not the case

besides, there is no format specification in section 3, and only a brief examle of one of the three use cases

I admit that § 3.1 format specification is not very well written, but it is there: "The text content <openpgp/> (BASE64_OPENPGP_MESSAGE) is a Base64 encoded, as specified in RFC 4648 [3] § 4, OpenPGP message which contains an encrypted and/or signed UTF-8 encoded string. Note that OpenPGP's ASCII armor is not used, instead the XMPP client MUST encode the raw OpenPGP message, as specified in RFC 4880 [4], using Base64. This string MUST represent exactly one OpenPGP content element, that is either a <signcrypt/>, a <sign/> or a <crypt/> extension element qualified by the 'urn:xmpp:openpgp:0' namespace."

also why use base64 over ascii armor?

because we encode the OpenPGP message

"This string MUST represent ..." maybe "correspond to" would be a better wording.

the OpenPGP message format also encodes whether it's a signed/encrypted message and which key-ids it is encrypted for. Why is this data duplicated inside?

key-ids != jids

wat

Ge0rG: I thougt "ascii armor" was base64?

Ge0rG, it looks like base64 is used INSTEAD of ascii armor, not over it?

moparisthebest: that's what I intended to say

and as for <signcrypt/>, <sign/> and <crypt>, for one, it is a fail safe, if an implementation constructs a <signcrypt/> message, because it wants to send a signed and encrtyped message, but only encrypts it using OpenPGP

Zash: yes, but with dashes and headers added.

oh so is it the same as the old spec? ascii armor stripped of whitespace and headers?

Flow: how should a client receiving such a failed message behave?

Ge0rG: What woud you suggest?

explosions

atomic ones?

I was thinking more firecracker-like

uhh :(

Ge0rG: Link Mauve asked a similar question just before you today. I don't have an answer other then "it should consider the message as unverified", and I don't think a spec should specify what a client should/must do if a message is unverified.

Light the thermite failsafe device

clients don't do nearly the same with with current pgp if decryption fails, I was messing around with this yesterday with a command-line pgp-capable sendxmpp command

moparisthebest: "don't do nearly the same"?

conversations displays "can't decrypt, maybe you don't have the right private key?" even when 'encrypted content' is 'bla'

and gajim sometimes displays the content of <body>, and sometimes shows no indication of having received a message at all

ahh

Flow, I'm saying they aren't consistent in what they do when receiving bad pgp encrypted messages

it would be nice if they were somewhat consistent though, I don't like gajim just dropping messages silently

you probably don't want to specify what exactly they should say, maybe you could just specify they should inform the user in some way?

what about sending an error back?

though what do you do if a client (of multiple) just doesn't have the right key?

Flow: by not having the redundancy, one could prevent the existence of these border cases.

Ge0rG: error as response of a presence has the potential for a presence leak, but if you check before sending that the entity has access to your presence anyway, then yes why not

and they could *get* the key later, due to the nature of pgp

like I set up conversations on a new phone and haven't set up openkeychain yet

sending an error as a response to a malformed message doesn't seem too far-reached

and do you still send the error back when you are retrieving with MAM ?

Ge0rG: I think a bad programmer is more likely to be able to construct an XML string prefixed with <signcrypt/>, <crypt/> and <sign/> then to use a OpenPGP library correctly

or do all your devices receiving the carbon send messages?

So it's not about removinga border case, but about having a fail safe for this case

there might be a difference to what you do if you don't have a key vs not-pgp, I'm not sure it'd be a problem outside of development

Flow: I think that adding this redundancy creates the border cases in the first place

"in the range of tenth of kilobytes" --> "in the range of tens of kilobytes" I suppose

the timestamp is redundant as well.

Yep

so a client may receive a message with three (different) timestamps. XEP-203, openpgp and <time>

which one do you display?

I would display <time>

Ge0rG: And possibly timestamps added by multiple different servers. ;)

xnyhps: Which remindes me, I wanted to reply to your latest mail on standards@

Timestamps are quite messy because it's not easy to say who to trust in general.

I'd be interested in persuing the added:by approach

And from what I can read, daniel too

I'd like to hear from some more server guys what they think about it

I believe most of the business rules from xep359 could go into the added:by xep

Flow: Some of them, yeah

Still not sure the complexity is really worth it.

xnyhps: That's basically why I didn't replly initially

My main reason was that the things the server strips might have changed between when the message was originally sent and when the client received it (from MAM), but as long as servers also strip messages outgoing on MAM that's not a problem.

Flow, might be useful to add a section about what to do if there are e.g. both an openpgp and a body element in a message or presence (iq obviously can’t have that).

Link Mauve: Hmmm, undecided, I personally don't think it is necessary

but patches welcome :)

XMPP-IM neither specifies what to do when a message with two <body/> arrives

(or maybe it does and I don't remember)

Flow: "For example, direct child elements found in either <signcrypt/>, <sign/> and <crypt/> could be: " <- shouldn't that read "For example, <payload/> child elements..."?

Ge0rG: Thanks, that is a leftover from the attribute to elements migration

fixing right now

Flow: also s/my/by/ in the §8.3 text

fixed

Flow: the link from §6.1 to http://tools.ietf.org/html/rfc4880#section-5.5.2 talks about key packets, not about message formats

I hope I didn't kill the OX thread with my long response.

Given the date, I’d even say the opposite. :)

Link Mauve: oh, right. I've been on holiday and missed it. Just found the time to read up, and the messages all were "new" to me

Ge0rG: it's just an example of packets where v4 must be used. The most important one, but just an example