Re: [Standards] Disappearing timers for OMEMO proposal

[VanitasVitae]

I might be mistaken, but isn't there a message processing hint, that indicates 
that the message should not be stored in MAM? Or was it the other way round?
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[VanitasVitae]

Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" :
>I don't see why a XEP for data retention hints needs to be tied to
>other XEPs like
>OMEMO, though.

I'd also rather not tie it to OMEMO. The same principle of disappearing 
messages could also be applied with other crypto in mind, or even no crypto at 
all. Remember, this functionality is not designed to give you any (serious) 
security improvements. Its rather a function which teenagers find neat and 
which was implemented in Signal for some reason.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

[VanitasVitae]

I would claim that a huge part of XMPP nowadays happens on mobile devices and I 
haven't seen a single rich text editor in any mobile application. Thats why I 
think that markdown is the way to go.

Sending greeting cards in html sounds like an idea from the 90s to me (not 
saying that it isn't a usecase, I just haven't come across it yet).

Am 15. März 2018 13:21:14 MEZ schrieb Kozlov Konstantin :
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

[VanitasVitae]

Also if we'd do that, we'd have "Message Markup" and "Message Markdown"...

Am 8. März 2018 17:23:32 MEZ schrieb Sam Whited :
>On Thu, Mar 8, 2018, at 10:18, Kozlov Konstantin wrote:
>> For example we may rename XEP-0393 to "Markdown" 'cause its syntax
>somewhat
>> similar to Markdown[1] language. 
>
>That seems even more confusing than the other suggestion, because we'd
>be naming it "markdown" even though it's not markdown (or even
>compatible with markdown). :)
>
>—Sam
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposal: Server selection for user-registration

[VanitasVitae]

Am 8. Januar 2018 23:57:20 MEZ schrieb Stefan  
>I see a problem with "choose server" right now, because:
>- Not every client developer wants to setup and maintain a good xmpp
>server by himself (ChatSecure for example).
>- Not every XMPP server is a good choice for the user. So if someone
>decides to not use the developer's server he needs to get further
>information, understand what MAM, Push, Stream Management, etc. means,
>find a server that supports that and register there or get that
>information from someone who explains this to him.

This reminds me of Diasporas https://podupti.me/ .
That is a site which offers an overview of all known servers and details about 
them (like uptime, version, features etc.)

It also has a button, which selects a random pod (server) for the user. I can 
imagine something like this might come in handy for new users.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] JET-OMEMO Encrypted Jingle Transports

[VanitasVitae]

Am 7. Oktober 2017 10:52:25 MESZ schrieb Jonas Wielicki :
>I would go with the simplest solution. IANAC (I Am Not A
>Cryptographer), but 
>AES-128-GCM-NoPadding sounds fine to me. There’s no need to add
>complexity 
>where none is needed.

So limiting ciphers to AES-128-GCM-NoPadding for OMEMO is the way to go for 
now. 

Thank you very much :)

Greetings vv
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

[VanitasVitae]

This means, that this XEP will specify the reusable stuff, while additional 
addon xeps will be created for different encryption methods.

Greetings vv

Am 20. September 2017 17:18:07 MESZ schrieb Sam Whited :
>On Tue, Sep 12, 2017, at 07:21, Paul Schaub wrote:
>> I just created a PR that addresses some of your feedback. A rendered
>> version can be found here:
>https://geekplace.eu/xeps/xep-jet/xep-jet.html
>
>Thanks!
>
>>  Split up the protocol into encryption method specific sub protocols
>(jet-omemo, jet-ox...)
>
>
>Can you clarify this TODO for me? Does this mean that two new XEPs will
>be submitted and this one will be withdrawn, or will this one remain?
>
>—Sam
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO Key Agreement

[VanitasVitae]

Hi Sebastian!

As a cryptographic expert, what would be your advise for future development of 
the protocol?

As you may have read, the reason of this discussion is the fact that there are 
concerns that it is not trivial to implement OMEMO in non-GPL apps due to the 
lack of a permissive XEdDSA implementation. Thats also the reason why OMEMO was 
(prematurely) specified based on Olm instead of libsignal.

Would you rather suggest to put the efforts into a permissive XEdDSA 
implementation or what would be your advice?

Greetings Vanitasvitae
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[VanitasVitae]

Regarding file transfer: I'll probably tackle that as part of my Google Summer 
of Code project, so we might get in contact later :)

Vanitasvitae

Am 18. Mai 2017 12:57:29 MESZ schrieb Andrey Gursky <andrey.gur...@e-mail.ua>:
>Hi,
>
>On Wed, 17 May 2017 16:59:53 +0100 Dave Cridland wrote:
>
>[ cut ]
>
>> A lengthy discussion ensued on this list, involving both Matthew
>> Hodgson and others who clearly know a lot more about Crypto than I
>do.
>> None of their arguments were answered. Remko supplied a PR to match
>> these. It seems to be being ignored, then rejected out of hand.
>
>My emails [1..4] and an email from another one [5] regarding OMEMO
>remained also without a response.
>
>Trying to discuss a quick fix of OMEMO jingle file-transfer was also
>not welcome [6] :(
>
>[ cut ]
>
>Regards,
>Andrey
>
>
>[1]
>https://mail.jabber.org/pipermail/standards/2016-December/031723.html
>[2]
>https://mail.jabber.org/pipermail/standards/2016-December/031724.html
>[3]
>https://mail.jabber.org/pipermail/standards/2016-December/031725.html
>[4]
>https://mail.jabber.org/pipermail/standards/2016-December/031736.html
>[5]
>https://mail.jabber.org/pipermail/standards/2016-December/031739.html
>[6]
>https://mail.jabber.org/pipermail/standards/2016-December/031737.html
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks

[VanitasVitae]

>> The signed preKeys are used for authentication.
>>
>
>I understand this is the idea, but where is this described in the
>Olm/OMEMO
>protocol? AFAICT, this is an X3DH thing, which Olm doesn't use.

This is not stated in the current Version of the XEP. I guess it would be good 
to put this into the next version?

>
>> Deviceid collisions with own devices are not allowed (the newer
>device has
>> to generate a new Id in that case). In mucs it doesn't really matter,
>since
>> the receiving device can simply try to decrypt with every matching
>keyId In
>> the message.
>>
>
>I guessed this, but when it comes to crypto, I don't like to guess
>things,
>and prefer to see things explicitly stated in a XEP.
>

I fear there is no practical workaround for this. Nevertheless it should be 
stated in the XEP as well.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

OMEMO works perfectly fine without changes on the server side (apart from 
implementing PEP/PubSub of course), so I really don't get the reason of the 
discussion :/

Am 25. März 2017 18:43:59 MEZ schrieb Evgeny Khramtsov :
>Sat, 25 Mar 2017 18:35:47 +0100
>Jonas Wielicki  wrote:
>
>> What’s your problem with another ejabberd developer implementing this
>> if they have interest in using that feature?
>
>I don't know about a core developer interested in OMEMO. This will be a
>contribution most likely. But then there is a problem with supporting
>contributed code.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

If you don't like the intention, then PGP is probably the way to go for you.

MAM is used to sync messages in OMEMO. Its unorthodox, but still totally valid.

Am 25. März 2017 12:49:21 MEZ schrieb Evgeny Khramtsov <xramt...@gmail.com>:
>Sat, 25 Mar 2017 11:48:56 +0100
>VanitasVitae <vanitasvi...@riseup.net> wrote:
>
>> But that's intended
>
>Well I don't like this intention.
>
>> If you want to search through your messages, the only way is to do it
>> in your local archive
>
>Then there is a little point in MAM, because you still need to keep
>a local copy.
>
>> The UX is relatively independent from the protocol I'd say
>
>I would disagree. The "trust" is a fundamental property of all
>crypto stuff, they don't work without trust. But a user doesn't
>understand this (probably due to poor UX): s/he doesn't understand what
>are all these fingerprints/QR codes for. Browser developers have learnt
>that and don't ask a user about trust anymore.
>
>> QR codes are already a step in the right direction
>
>Not that much, users will still be puzzled, imho.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

You cannot search Messages server side, that's true. But that's intended and I 
guess there is no way to achieve this while preserving forward and future 
secrecy. If you want to search through your messages, the only way is to do it 
in your local archive.

An interesting feature would be to enable a device to reencrypt messages for 
new device. That feature must not get triggered automatically though and should 
only be done from explicit user request. That way you could synchronize 
messages with devices that got registered after the messages have been sent.

The UX is relatively independent from the protocol I'd say. Yes, you should 
have the user manually trust contacts devices, but I guess there are more 
clever ways to do this rather than comparing the fingerprint (QR codes are 
already a step in the right direction, but I'd consider researching more in 
things like a web of trust or (as I once proposed in the mailing list) have 
transitive trust between a users devices).

Am 25. März 2017 10:50:02 MEZ schrieb Evgeny Khramtsov :
>Sat, 25 Mar 2017 08:43:34 +0100
>Philipp Hörist  wrote:
>
>> Can you go more into detail?
>> Why cant you search your OMEMO Messages?
>
>How to do this in MAM archive, server-side?
>
>> And what is the problem with losing a Device?
>
>If I lose a single device I have (or it gets broken, whatever), I lose
>access to all my MAM messages, because I lose the key.
>
>Another problem is UX: it's just terrible. Imagine an inexperienced
>user who sees something like "OMEMO fingerprint", or "Clean
>devices" (an example from Conversations). The first his question is
>"WTF
>is this???". This is the same problem as with PKIX certificates,
>like asking whether a user trusts a certificate or not: this just
>doesn't work.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks

[VanitasVitae]

Hi!

The signed preKeys are used for authentication.

The deviceId is a 31 bit integer because of libsignals implementation I guess.

Deviceid collisions with own devices are not allowed (the newer device has to 
generate a new Id in that case). In mucs it doesn't really matter, since the 
receiving device can simply try to decrypt with every matching keyId In the 
message.

Also the signal protocol works just the same with mucs as it does with single 
user chats. You simply forward all the ratchets of all recipients.

Kind regards
Vanitasvitae

Am 13. März 2017 09:32:29 MEZ schrieb "Remko Tronçon" <re...@el-tramo.be>:
>Hi,
>
>I have a few questions/remarks about XEP-0384:
>
>- The examples mention signed pre-keys. This isn't part of the Olm
>protocol
>AFAICT, I only saw it in the original double ratchet spec. Is this a
>remnant of an older version of the XEP? Should this be dropped, or is
>the
>plan to use X3DH eventually?
>
>- The XEP uses AES128-GCM for encryption, which seems different from
>Olm
>(which uses AES256-CBC). I know very little about crypto, but is there
>a
>reason for going with AES128 instead of AES256? I'm asking, because on
>first sight, it seemed easier to find support for AES256-GCM (e.g. in
>libsodium/nacl) than for AES128-GCM.
>
>- I can't find a reference in the XEP on how the ratchet algorithm
>works in
>multi-user settings (there's only a reference to Olm, which AFAICT only
>works for single users). Is this where megaolm steps in? Should there
>be a
>reference to a protocol?
>
>- The Device ID being a randomly generated 32-bit integer seems out of
>the
>ordinary? Not that the chances of collisions in a big MUC are *that*
>big,
>but would a GUID be more consistent with some previous XEPs? Should
>something be said about what to do when recipient device IDs collide?
>
>- Cosmetic: camel case is used for tags/attributes, whereas I believe
>kebab-case is more consistent with other XEPs?
>
>thanks!
>Remko

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___