Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

[Thijs Alkemade]

> On 11 mei 2016, at 00:09, Matthew Wild <mwi...@gmail.com> wrote:
> 
> On 10 May 2016 at 20:28, Thijs Alkemade <m...@thijsalkema.de> wrote:
>> 
>>> On 28 apr. 2016, at 08:35, XMPP Extensions Editor <edi...@xmpp.org> wrote:
>>> 
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> 
>>> Title: XMPP Compliance Suites 2016
> 
>> I don't really understand the point of CSI being required for Advanced 
>> Client.
>> Do non-mobile clients have to implement it and never send ? Or do
>> servers have to disable all optimizations because enabling CSI is no longer 
>> an
>> implicit "I'm a mobile client with my screen off"?
> 
> I don't think there's anything that makes CSI mobile-only. If I had a
> laptop on battery and tethered, I would care about the resource
> consumption of my desktop client as much as I'd care about a mobile
> client. I would expect it to send  when all its windows are
> hidden (e.g. minimized) or if my computer screen is locked, etc.
> 
> Regards,
> Matthew

Lets look at the suggested optimizations from the XEP:

> Suppress presence updates until the client becomes active again. On becoming
> active, push the latest presence from each contact.

This only makes sense if the client has no way to show when someone was last
online and if it doesn't notify of users signing on (even when the screen is
off there might be a sound notification).

In a MUC, you'll miss someone joining and immediately parting. If you are a
moderator that can be a security issue because you won't know their real JID:
someone could join with an offensive nick and as long as they part quickly
enough they can't be banned.

> Discard messages containing only Chat State Notifications (XEP-0085) [2]
> payloads.

I don't see how this is a good idea either unless you don't implement Chat
State Notifications in the receiving client: if I get a  but not the following
 someone might show
up as "Typing..." for hours. Do I have to reset all chat states when
deactivating CSI?

> Defer or discard unimportant PEP notifications, possibly unsubscribe from
> certain PEP nodes until the client becomes active again.

I'm not familiar enough with PEP to really understand the implications of
this, but this too sounds like something the server should interfere with
without the client knowing exactly what's happening.

I think the XEP would be valuable for every client if it only alled the server
to delay stanzas for a short while and bundling them, but that's not the case.

Regards,
Thijs





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

[Thijs Alkemade]

> On 28 apr. 2016, at 08:35, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: XMPP Compliance Suites 2016
> 
> Abstract:
>  This document defines XMPP protocol compliance levels for 2016.
> 
> 
> URL: http://xmpp.org/extensions/inbox/compliance2016.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

Hi,

I don't really understand the point of CSI being required for Advanced Client.
Do non-mobile clients have to implement it and never send ? Or do
servers have to disable all optimizations because enabling CSI is no longer an
implicit "I'm a mobile client with my screen off"?

Regards,
Thijs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Thijs Alkemade]

> On 16 feb. 2016, at 17:18, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Instant Stream Resumption
> 
> Abstract: This specification introduces an mechanism for instant
>  stream resumption, based on Stream Management (XEP-0198), allowing
>  XMPP entities to instantaneously resume an XMPP stream.
> 
> URL: http://xmpp.org/extensions/inbox/isr.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.


I'll just repeat my point that all quick connection attempts so far seem to
throw out mutual authentication without hesitation. That may be an acceptable
trade-off in certain scenarios, but it should be emphasized that it decreases
security.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Thijs Alkemade]

> On 5 feb. 2016, at 17:15, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Token-based reconnection
> 
> Abstract: This specification defines a token-based session authentication 
> mechanism similar to OAuth.
> 
> URL: http://xmpp.org/extensions/inbox/token-reconnection.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

As it is currently written this looks like a rather bad idea to me, or at
least needs a much longer Security Considerations section than it currently
has.

SCRAM offers protection from replay-attacks, mutual authentication and
optionally channel binding. Not only does this specification give up on all of
those, but it also makes it trivial for an active attacker to cause a
reconnection where SCRAM will be downgraded to this. One of suggestion to fix
is by requiring the client to verify that the server's certificate is
unchanged.

Other comments:

* It's named "X-OAUTH". How does it compare to RFC 7628?

* It should probably have a disco feature so the client can determine whether
  it can retrieve a token.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Thijs Alkemade]

> On 5 feb. 2016, at 20:04, Lance Stout  wrote:
> 
> 3) This does not really decrease the initial authentication and subsequent
> stream setup time. It is still using the full SASL process, so time wise
> it is exactly the same as PLAIN. It is exactly one round trip faster than
> SCRAM-SHA-1. It does use less hashing, which I agree can have a noticeable
> delay in some browsers; however, the derived materials generated during
> SCRAM-SHA-1 can be cached to significantly reduce the calculation time
> for subsequent logins, and also serve as a secure replacement for the
> plaintext password (which is also revokable by the server using a new salt).

I agree with most of your points, however, the salt can only be changed by the
server if the server is not using hashed storage. If the server stores only
ServerKey and StoredKey (plus the salt and iteration count) it can not change
the salt without downgrading to PLAIN or resetting the user's password. I
think the iteration count can be increased with hashed storage, but I'm not
100% sure.

Provided the client has cached the ClientKey and StoredKey the only intensive
computations are 3 times HMAC-SHA1. This will likely be negligible even on
phones.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

[Thijs Alkemade]

> On 20 jan. 2016, at 19:16, Daniel Gultsch  wrote:
> 
> Hi,
> 
> while I see the general need for the added x Element in forwarded muc 
> messages. (I think i brought this up myself once in an earlier thread.) This 
> is missing a 'Security Consideration' that servers must remove the x element 
> if a users sends it. (In case the server is storing the entire stanza and not 
> just the Content of the body element.) Otherwise users can very easily spoof 
> messages as being from a different sender.
> 
> However the main problem is that even if the server removes those elements as 
> a client I still can't trust them because I don't know whether the server has 
> added the element or a malicious user.
> 
> I was always meaning to spark a conversation about server injecting elements 
> into stanzas that don't originate from them. (ejabberd for example is already 
> injecting the stanza-id (which don't get me wrong is a good thing in theory.) 
> The problem is not to sanitize those stanzas on the server side the problem 
> is that i don't know as a client.
> 
> I don't have a good solution to this yet and this should definitely go into a 
> different thread by maybe something about a special attribute for example 
> 'by' that indicates who injected that tag and a general rule to remove all 
> elements that have the attribute by with my entity - or something.
> 
> cheers
> Daniel

Hi Daniel,

I sent a proposal for that back in June [1], but that didn't receive a lot of
responses, just Kev noting that namespaced attributes aren't very common in
XMPP [2].

There are alternatives to using a namespaced attribute, but I fear those won't
be backwards compatible. Unless there are implementations out there that have
major problems working with namespaced attributes, I don't think we should
avoid them just for being rare.

Regards,
Thijs


[1] = http://mail.jabber.org/pipermail/standards/2015-June/029847.html
[2] = http://mail.jabber.org/pipermail/standards/2015-October/030514.html



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Thijs Alkemade]

> On 19 jan. 2016, at 17:49, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Content Types in Messages
> 
> Abstract: This specification describes a generic method whereby content in 
> messages can be tagged as having a specific Internet Content Type. It also 
> provides a method for sending the same content using different content types, 
> as a fall-back mechanism when communicating between clients having different 
> content type support.
> 
> URL: http://xmpp.org/extensions/inbox/content-types.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

The Security Considerations section of this proto-XEP is missing, though
XEP-0001 §12 requires every XEP to have one. For this XEP, I don't think an
empty section would suffice because it really should discuss consistency.

Should a client try protect the user from receiving a message that contains
multiple content types with completely different meanings? If I'm reading back
the log of a conversation on a different device, can I trust that the messages
I see there are the same messages I actually responded to? The conversation
could be completely different on two clients supporting different sets of
content types. This can be abused quite easily to scam people or to create
incriminating logs.

Yes, we already have the same problem with XEP-0071, but with only two
different formats it is still manageable to fix it, for example by deprecating
the use of . If we add the ability to add many different
representations to a message then consistency will be a lost cause forever.

Regards,
Thijs




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Thijs Alkemade]

> On 23 dec. 2015, at 20:18, Andreas Straub  wrote:
> 
>>> 
>>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
>>> impossible to implement OMEMO from scratch by the current documentation 
>>> alone.
>>> “Axolotl” has no standard, and it appears Open Whisper Systems has no
>>> intention of writing one. The few bits of documentation and blog posts that 
>>> we
>>> have are not enough to implement it and are outdated or wrong in some 
>>> places.
> 
> To give some context to those that haven't been following this in
> detail, there are two different versions of the TextSecure protocol that
> are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was
> OTR-based. There is publicly-available documentation of the
> cryptography[1] and wire protocol[2] used in v2. These are not exactly a
> standard, but do describe the protocol pretty clearly.
> 
> Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some
> variations on the underlying cryptography, along with corresponding
> changes of the wire protocol. Neither of those things are publically
> documented anywhere to the best of my knowledge. For this reason there
> has been some justifiable resistance towards OMEMO. I agree that this is
> a problem, and in light of this fact, I understand hesitation to proceed
> with standardization of OMEMO in its current form.
> 
> I don't think that getting the Open Whisper Systems people to write up a
> spec of v3 for us is realistic, and I wouldn't feel comfortable with
> writing up this spec myself. What I propose is that we change the OMEMO
> spec to REQUIRE conforming implementations to support v2. We would
> further make it OPTIONAL to support v3 as well, as many client
> developers will likely re-use existing implementations of axolotl, most
> of which support both versions.
> 
> The scenario of interest is establishing a new session. Let's say Alice
> wants to talk to Bob. Alice can discover whether Bob supports v3 by
> checking whether a signedPreKeyPublic and corresponding
> signedPreKeyPublicSignature are present in Bob's published preKeyBundle
> as these items were added in v3 (We might also explicitly announce v3
> support in the XML here, I don't really feel strongly about this either
> way, although I don't think it's necessary). If Alice supports v3, and
> so does Bob, they can use v3 to establish their connection. If Alice
> supports v3, but Bob doesn't, Alice will realize this and fall back to
> v2. If Alice doesn't support v2, regardless of whether Bob does or not,
> Alice will simply ignore the signedPreKeyPublic and signature as she
> isn't aware of them, and establish a v2 session. Therefore, in this
> scheme we obtain automatic, transparent version negotiation (of sorts)
> for free.
> 
> As a side-note on the cryptographic differences/benefits introduced with
> v3, there's not any documentation I could find that states the intent
> behind the changes. I won't speculate or make educated guesses as to the
> precise reasons at this time, but I will say that in any case, v3 does
> not appear to be less secure than v2, so allowing its use in an OPTIONAL
> fashion shouldn't decrease the security of the protocol. Further,
> distrusting clients can always chose not to announce support for it if
> they're dissatisfied with its unspecified nature.
> 
> In conclusion, we can (mostly) resolve the standardization issues with
> axolotl using the previously described change, with no immediately
> obvious downsides. I would be interested in hearing some feedback on
> whether those parties previously dissatisfied with OMEMO for this reason
> agree that using v2 is a workable solution to the specification dilemma.
> In that case I would draw up the necessary alterations to the ProtoXEP.
> I would further be interested in opinions on the issue of whether the
> documentation that is available on v2 is deemed sufficient for an
> independent implementation, and if not, in what manners it is lacking,
> so please take a look!

Even for v2 I'm not convinced the existing documentation is enough to
implement it. For example, the hashing algorithm used for the HKDF steps is
not documented in either link you provided (sure, it's probably SHA-256, but
it's an important detail). The documentation is also rather hard to follow,
has irrelevant sections (SMS fragmentation) and lacks in argumentation for
their choices.

I would still prefer if some people wrote a specification for (or based on)
axolotl that's self-contained and declared the authority for interop. OTR is
11 years old, so we really should aim to write something that can stand for a
multiple decades. If at some point Whisper Systems stops updating libaxolotl
and the repositories disappear and a new security issue is discovered then we
still need to be able to understand it and investigate how to fix it. The Olm
specification [1] is pretty close to what I would like to see (the level of
detail, not the 

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Thijs Alkemade]

> On 5 nov. 2015, at 20:52, Georg Lukas  wrote:
> 
> My gut feeling is that really restrictive firewalls will either
> completely block the ALPN extension (breaking SPDY as well), or
> implement ALPN parsers and whitelist HTTP only.
> 
> This will probably only be solved by TLS1.3, which is still three major
> protocol meltdowns away (TLS1.0, 1.1 and 1.2 ;-))

While SNI/ALPN encryption for the ClientHello was discussed for TLS 1.3, I
think it was ultimately dropped as it added too much extra complexity (but
maybe there's someone here who follows the TLS WG more closely).

Encryption of the server's extensions is still supported, though, so the
selected ALPN protocol can be hidden.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] UPDATED: XEP-0333 (Chat Markers)

[Thijs Alkemade]

> On 28 okt. 2015, at 16:50, XMPP Extensions Editor  wrote:
> 
> Version 0.2.1 of XEP-0333 (Chat Markers) has been released.
> 
> Abstract: This specification describes a solution of marking the last 
> received, displayed and acknowledged message in a chat.
> 
> Changelog: Fixing typo ("cannot" repeated twice) (JC Brand). (XEP Editor 
> (mam))
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0333/diff/0.2/vs/0.2.1
> 
> URL: http://xmpp.org/extensions/xep-0333.html 
> 

I tried to read this specification today, and it left me rather confused.

From the introduction it is not clear to me how Chat Sate Notifications +
Carbons is insufficient.

§4 has two examples where the client queries a server for support, but the
entire specification reads as if it only applies to clients.

Lastly, it says in §6:

> If recipient does not support the Chat Markers protocol it SHOULD NOT return 
> an error.

While it does sound like a very sensible requirement, extensions shouldn't be
able to set requirements for all implementions that don't support it.

Regards
Thijs



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

[Thijs Alkemade]

> On 13 sep. 2015, at 15:50, Sam Whited  wrote:
> 
> I was experimenting with OTR a bit today and was going to tweak this
> section of the document, but I think I'm still siding with Daniel on
> this one and am not going to make any change at the moment: Sending to
> the full JID just doesn't work with OTR in practice.
> 
> Does any client actually use instance tags to discard junk messages?
> After a (very cursory) search over some popular clients I didn't see
> any of them using instance tags. Would love to be told otherwise
> though.

libotr does:

https://bugs.otr.im/projects/libotr/repository/revisions/master/entry/src/message.c#L994

otr4j does:

https://github.com/jitsi/otr4j/blob/bfd0b363a9a7865f68e46db19c095a8f34ace6be/src/main/java/net/java/otr4j/session/OtrAssembler.java#L96

AFAICT those two together cover a great number of clients.

The only implementation of OTR I could find that does not support instance
tags is pure-python-otr:

https://github.com/python-otr/pure-python-otr/issues/28

Best regards,
Thijs



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

[Thijs Alkemade]

> However, OTR requires that messages be sent to a particular resource. 
> Therefore clients SHOULD send OTR messages to a full JID, possibly allowing 
> the user to determine which resource they wish to start an encrypted session 
> with.

This is no longer true with OTR v3. This version added “instance tags” which
can distinguish different clients signed in to the same account.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] MUC2

[Thijs Alkemade]

 On 25 jun. 2015, at 10:27, Kevin Smith kevin.sm...@isode.com wrote:
 
 Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve 
 pretty much killed off fully anonymous rooms in MUC1.
 
 Can people share their thoughts on usecases for semi-anon, please? It’s not 
 entirely clear to me what these are (users who want anonymity seem to already 
 be using throw-away JIDs to achieve that, instead of relying on MUC 
 configuration).

1. Privacy.
2. To not turn public MUCs into treasure troves for spam bots. All of these 
JIDs have an active client signed in, so they are great targets.
3. Best practices currently dictate that resources should be random, as they 
are privacy-sensitive. That’s almost opposite of revealing it to everyone in a 
room.

Thijs

[Standards] Added elements (was: Proposed XMPP Extension: Unique and stable message IDs)

[Thijs Alkemade]

 On 4 jun. 2015, at 11:26, Matthew Wild mwi...@gmail.com wrote:
 
 I would probably go for the same approach as the original archived/
 element in MAM, and have a 'by' attribute (similar also to delay/):
 
   message-id id=1234-- by=example.com http://example.com/ /
 
 This would also allow clients to use it if they really wanted to, by
 putting their JID in the 'by'.

I fully admit that this is going to sound like an over-engineered solution to
a rare and unimportant problem, but anyway.

Servers adding elements to stanzas is tricky because the client needs to
determine whether it was actually that server that added them, not the sender
or some other server along the line, and I fear clients might mess up that
check. delay has the exact same problem.

Your server can't strip out elements that it knows nothing about. But instead
of adding stripping support for every new XEP to all servers, how about
making a new, general, XEP to indicate who added elements? For example, adding
a single attribute 'by' in a new namespace:

delay
   xmlns='urn:xmpp:delay'
   stamp='2002-09-10T23:41:07Z'
   added:by='conference.example.lit'
   xmlns:added='urn:xmpp:added' /

message-id
   xmlns='urn:xmpp:mid:0'
   id='de305d54-75b4-431b-adb2-eb6b9e546013'
   added:by='muc.capulet.lit'
   xmlns:added='urn:xmpp:added' /

This means the server does not need to know the XEP used to strip those
elements out, it can just remove all elements that have a 'added:by' value
that is obviously incorrect. As they are in a new namespace, the original
XEPs don't need to be updated and clients that don't understand this
specification can easily ignore them.

Alternatively, we could give 'from', as it is already used by Delayed
Delivery, extra meaning, (like required/ in stream features), but I fear
that may have unintended consequences.

Of course this doesn't protect clients from servers maliciously adding,
removing or changing elements, it only protects users from others
impersonating their own server.

Regards,
Thijs



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] XMPP OAuth2 login at Google

[Thijs Alkemade]

[Reviving a very old thread]

It looks like today is going to be the day Google shuts down ClientLogin [1],
and with that, SASL PLAIN [2]. This might be the final nail in the coffin of
XMPP support for Google Talk, as I fear few clients have implemented X-OAUTH2.

We have an update in beta for Adium, but working on that while knowing Google
could shut down the XMPP interface any day was not very motivating.

Thijs

[1] = https://developers.google.com/identity/protocols/AuthForInstalledApps
[2] = 
http://googledevelopers.blogspot.com/2012/09/adding-oauth-20-support-for-imapsmtp.html


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] XMPP OAuth2 login at Google

[Thijs Alkemade]

 On 20 apr. 2015, at 10:15, Thijs Alkemade th...@xnyhps.nl wrote:
 
 [Reviving a very old thread]
 
 It looks like today is going to be the day Google shuts down ClientLogin [1],
 and with that, SASL PLAIN [2]. This might be the final nail in the coffin of
 XMPP support for Google Talk, as I fear few clients have implemented X-OAUTH2.
 
 We have an update in beta for Adium, but working on that while knowing Google
 could shut down the XMPP interface any day was not very motivating.
 
 Thijs
 
 [1] = https://developers.google.com/identity/protocols/AuthForInstalledApps
 [2] = 
 http://googledevelopers.blogspot.com/2012/09/adding-oauth-20-support-for-imapsmtp.html

False alarm, apparently, in last February they made a new post [1] stating:

We’ve taken steps to provide alternatives to password authentication in other
protocols as well. CalDAV API V2 only supports OAuth 2.0, and we’ve added
OAuth 2.0 support to IMAP, SMTP, and XMPP. While a deprecation timeline for
password authentication in these protocols hasn’t been announced yet,
developers are strongly encouraged to move to OAuth 2.0.”

Thijs

[1] = 
http://googledevelopers.blogspot.com/2015/02/reminder-clientlogin-shutdown-scheduled.html


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

[Thijs Alkemade]

 On 18 apr. 2015, at 11:59, Thijs Alkemade th...@xnyhps.nl wrote:
 
 
 On 18 apr. 2015, at 11:42, Georg Lukas ge...@op-co.de wrote:
 
 1. When a user logs in for the first time, an asymmetric keypair is
 created (I was thinking of Curve25519, where key creation is almost
 free). The private key is encrypted with a key derived from the user
 password / SASL state (https://www.zash.se/mod_storage_encfs.lua.html is
 a PoC for that).
 
 2. All data that is stored for the user is encrypted with their public
 key and appended to their container.
 
 What do you mean with “SASL state”? All of the data the server has after a
 SCRAM-SHA-1 exchange is either a) stored on the server, b) session specific.
 You can’t derive a key from that which the server could not derive on its own.

Zash pointed out to me that I was wrong. The ClientKey does not change between
sessions, is not stored on the server (during normal operation) and the server
does compute it during login. It could be used to derive a key.


Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

[Thijs Alkemade]

 On 18 apr. 2015, at 11:42, Georg Lukas ge...@op-co.de wrote:
 
 1. When a user logs in for the first time, an asymmetric keypair is
 created (I was thinking of Curve25519, where key creation is almost
 free). The private key is encrypted with a key derived from the user
 password / SASL state (https://www.zash.se/mod_storage_encfs.lua.html is
 a PoC for that).
 
 2. All data that is stored for the user is encrypted with their public
 key and appended to their container.

What do you mean with “SASL state”? All of the data the server has after a
SCRAM-SHA-1 exchange is either a) stored on the server, b) session specific.
You can’t derive a key from that which the server could not derive on its own.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Thijs Alkemade]

On 26 jan. 2015, at 10:10, Georg Lukas ge...@op-co.de wrote:

 * Bartosz Małkowski bmalkow...@tigase.pl [2015-01-26 07:58]:
 https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/

Hi,

Author of the post here, nice to see it’s already being discussed.

 This is a great writeup. Having multi-device end-to-end encryption
 with offline storage will significantly improve the security and
 usability of XMPP for normal people.
 
 I'd like to add some more points to the discussion though:
 
 a) it is important to allow security-conscious people to actually check
 the security properties, so the list of devices/keys/fingerprints needs
 to be exposed to power users, plus additional information messages when
 the list is extended.

Agreed completely.

 b) a protocol/approach for adding devices to the list needs to be
 created, maybe deploying some kind of cross-signing between one old and
 the new device?

Good point, I haven’t covered that, but adding new devices will indeed be
more complicated than it is now.

One way this could work is that you need one of the devices that already has a
key on your account to bootstrap the new device (signing the new device's
public key with its key). If the old device has some local logs, it could push
some to the new device to still give it some backlog (re-encrypted with the
new device’s key).

But it does create a barrier for users. I know Firefox Sync did something like
that (requiring you to input some characters from the browser on one device on
the new one to add it to the sync), but apparently too many people didn’t like
it, so it was removed.

 c) it would be great to leverage this to secure file transfers / uploads
 as well as media streams.

If you just want to exchange one symmetric key, that should work fine. But
using the protocol itself for filetransfers/media streams is likely going to
give bad performance.

 d) multi-device end-to-end encryption can also elegantly solve the MUC
 security problem. Let's do it so.

I don't think this solution will scale well to a group chat with more than ~10
people. The number of devices people have will likely be limited in practice,
but the number of participants in a group chat can get quite large. I think
there are better solutions for encrypting MUCs.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] SASL Negotiation in XMPP Core introduces potential security concern

[Thijs Alkemade]

Hi Sam,

 On 8 dec. 2014, at 21:45, Sam Whited s...@samwhited.com wrote:
 
 aIn XMPP CORE (RFC 6120) §6.3.3:
 
 the client's ordered list is GSSAPI SCRAM-SHA-1, the client MUST 
 try GSSAPI first and then SCRAM-SHA-1
 
 Suggests that when authing with SASL we should fallback if auth fails
 (eg. if both server and client support SCRAM-SHA-1 and DIGEST-MD5, and
 SCRAM-SHA-1 auth fails, we should fallback and attempt auth with
 DIGEST-MD5). Am I reading this correctly?
 
 If so, is this not a potential security concern? Imagine the scenario
 described above over an unencrypted (no TLS) connection. An attacker
 could inject arbitrary data (shaped like an auth challenge stanza) into
 the stream to force SCRAM-SHA-1 to fail, then simply record the
 DIGEST-MD5 auth which is easier to break.

Are you suggesting a scenario where the attacker can *insert* data that causes
DIGEST-MD5 to be used, but can not just *remove* the SCRAM-SHA-1 offer, only
leaving DIGEST-MD5? That sounds rather far-fetched to me. In practice, either
an attacker can make arbitrary modifications, or none at all (due to TLS).

 Am I missing something here? It seems to me that the client should pick
 its prefered (presumably the most secure) auth method that is also
 supported by the server and refuse to do anything else (trusting that if
 the server is advertising it, it's actually supported).

The point of using another mechanism is that you can't assume, in general,
that the server will only offer a mechanism when it supports it, because the
server does not yet know what user you will authenticate as. Maybe it has
SCRAM hashes for some users, but still wants to offer DIGEST-MD5 for the
others.

Obviously a client shouldn't use a mechanism if it isn't secure, like PLAIN
without TLS, but falling back to a different mechanism doesn't change that.

 The only problem I can see here is that if the SASL mechanism has
 different sub-mechanisms (I'm unsure what to call that; eg. if we're
 using SCRAM-SHA-1-PLUS and the information the server and client are
 using different forms of channel binding) this could cause a failure at
 the SASL level which XMPP wouldn't be aware of (and since it wouldn't
 fall back we couldn't authenticate). However, this is very unlikely as
 far as I can tell.
 
 If this is the case, it seems like a SASL method pinning scheme should
 be used (so after we have a successful login, then we refuse to do
 anything else). This way, as long as the first connection works, we
 mitigate the attack described above (just like HTTP TLS cert pinning, or
 any other pinning scheme).

Pinning the mechanism used sounds like a good idea to me, though I would say
clients should refuse to use anything weaker.

Best regards,
Thijs

Re: [Standards] Deprecating XEP-0138: Stream Compression

[Thijs Alkemade]

On 9 okt. 2014, at 17:06, Peter Saint-Andre - yet pe...@andyet.net wrote:

 On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
 Hello all,
 
 Stream compression is insecure, that was shown with CRIME and BREACH and the
 situation for XMPP isn't much different [1]. I think we should look at the
 easiest way to deprecate XEP-0138 and move to something better.
 
 Using a full flush (in zlib terms) after every stanza would solve the
 problem, as I can't find any realistic examples where an attacker could 
 insert
 their own payload into the same stanza as something secret they want to know.
 However, clients and servers have no way to negotiate a mode like that, so
 it's not possible to reject connections that won't do a per-stanza full 
 flush.
 Reading draft-ietf-hybi-permessage-compression-18, I was happy to see that 
 this
 could be negotiated in WebSocket extension [2].
 
 From my own (very small scale) tests with raw XMPP XML, it appears that full
 flushing after every stanza yields about the same compression ratio as
 compressing each stanza separately. Doing that would have a number of
 advantages:
 
 1. Not relying on nothing leaking through the full flush, which may be a
 concept that other compression algorithms than zlib don't have or don't do
 securely enough.
 
 2. Practically no memory overhead in the server or client between messages.
 There's no context to keep around, each new message can be decompressed with 
 a
 fresh new context. Memory overhead for compression is a real concern for
 servers: one of the reasons Prosody was pushing for XEP-0138 to replace TLS
 compression was that it's impossible configure the memory use of TLS
 compression to sane levels in OpenSSL.
 
 However, it also has downsides. It requires either:
 
 1. That the concatenation of two compressed stanzas can be separated
 unambiguously.
 
 Could you explain that a bit more? For example, are you talking about 
 compressing two stanzas and sending them in the same TCP packet?

Instead of sending:

zlib(“message/iq/message/iq...”)

(Where you’d occasionally send the compressed data you have so far.)

You'd send:

zlib(“message/”) + zlib(“iq/”) + zlib(“message/”) + zlib(“iq”)

(Where + is concatenation.)

This is easy in zlib because it’s possible to tell when a zlib stream ends 
[1][2].

 
 2. Or that we apply framing outside of compression (which I expect to be
 another can of worms).
 
 Yes, I'd expect so. I recall debates about framing (or the lack thereof) for 
 XMPP on this very list from over 10 years ago. ;-)
 
 a zlib has a header bit that indicates whether a block is the last block in a
 stream, but again, that might be zlib-specific.
 
 Would it be worthwhile to investigate what the various compression algorithms 
 support here?

I've been trying to look into LZW, as it is described by XEP 0229, but while I
can find enough descriptions of the algorithm itself, I can't find much about
the output encoding. Most of the LZW API's I've seen also have no flush-method
or something similar.

Regards,
Thijs

[1] = http://zlib.net/manual.html:

If the flush parameter is Z_FINISH, the remaining data is written and the
gzip stream is completed in the output. If gzwrite() is called again, a new
gzip stream will be started in the output. gzread() is able to read such
concatented gzip streams.

[2] = https://docs.python.org/2/library/zlib.html#zlib.Decompress.unused_data



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Standards] Deprecating XEP-0138: Stream Compression

[Thijs Alkemade]

Hello all,

Stream compression is insecure, that was shown with CRIME and BREACH and the
situation for XMPP isn't much different [1]. I think we should look at the
easiest way to deprecate XEP-0138 and move to something better.

Using a full flush (in zlib terms) after every stanza would solve the
problem, as I can't find any realistic examples where an attacker could insert
their own payload into the same stanza as something secret they want to know.
However, clients and servers have no way to negotiate a mode like that, so
it's not possible to reject connections that won't do a per-stanza full flush.
Reading draft-ietf-hybi-permessage-compression-18, I was happy to see that this
could be negotiated in WebSocket extension [2].

From my own (very small scale) tests with raw XMPP XML, it appears that full
flushing after every stanza yields about the same compression ratio as
compressing each stanza separately. Doing that would have a number of
advantages:

1. Not relying on nothing leaking through the full flush, which may be a
concept that other compression algorithms than zlib don't have or don't do
securely enough.

2. Practically no memory overhead in the server or client between messages.
There's no context to keep around, each new message can be decompressed with a
fresh new context. Memory overhead for compression is a real concern for
servers: one of the reasons Prosody was pushing for XEP-0138 to replace TLS
compression was that it's impossible configure the memory use of TLS
compression to sane levels in OpenSSL.

However, it also has downsides. It requires either:

1. That the concatenation of two compressed stanzas can be separated
unambiguously.

2. Or that we apply framing outside of compression (which I expect to be
another can of worms).

zlib has a header bit that indicates whether a block is the last block in a
stream, but again, that might be zlib-specific.

Thoughts? Comments?

Best regards,
Thijs Alkemade

[1] 
https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/
[2] 
https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18#section-8.1.1


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Carbons - inbound messages to bare jid

[Thijs Alkemade]

On 25 apr. 2014, at 13:32, Kim Alvefur z...@zash.se wrote:

 Hello,
 
 It has been brought up that my Carbons implementation does not follow
 the Receiving Messages to the Bare JID¹ section.  This section says
 include carbons-enabled sessions in the normal forking of messages as
 described by XMPP IM².
 
 What I implemented was instead to send carbons-wrapped messages to
 carbons-enabled sessions that would not already receive them based on
 the XMPP IM rules.  So a message will always be carbons-wrapped if it
 was sent because carbons was enabled.  I believe this makes sense, does
 anyone else?
 
 ¹ http://xmpp.org/extensions/xep-0280.html#inbound-bare (version 0.9)
 ² http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1

Hi Kim,

Thinking about this a bit more, I actually disagree with this proposal.

The semantics of receiving a carbon copy should be hey this other resource
has a conversation going, here's a copy of this message in case you want to
follow along. That might imply, for example, that the client uses a different
way of notifying the user: the user might have configured their client to not
make a sound when receiving a carbon copy, as multiple devices making sounds
gets annoying.

A bare-JID message is a different situation. Sending one implies the sender is
looking for a resource that will reply to start a conversation with it, so for
these I think it would be fine if a carbons-enabled client notifies the user
as if it were a normal message.

Of course the client could add extra logic for this (if it's a carbon copy,
and the first message we've seen from this user this session/hour/day, play
sounds), but I think doing it in the way that is currently in the XEP is a
much cleaner solution.

Regards,
Thijs Alkemade


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] MAM IDs

[Thijs Alkemade]

On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote:

 In MAM, stanzas stored get stamped with a MAM ID by the entity that
 stored them, and entities receiving them then receive this.
 
 So a general question - are these useful? Are clients going to ignore
 them and just request all history since they last requested it anyway?
 
 /K

Because querying by date range is unreliable, and should be avoided wherever
possible. The client's and the server's clock could be minutes apart and even
if they were synchronized then multiple messages arriving in the same second
can lead to difficult edge cases.

I'd much rather query by the UUID injected into a message than by the
approximate datestamp.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] compression attacks

[Thijs Alkemade]

On 17 feb. 2014, at 14:29, Winfried Tilanus winfr...@tilanus.com wrote:

 Signed PGP part
 On 13-02-14 13:19, Thijs Alkemade wrote:
  On 13 feb. 2014, at 01:04, Peter Saint-Andre stpe...@stpeter.im
  wrote:
 
  While working on draft-sheffer-uta-tls-attacks with Yaron
  Sheffer this week, he pointed out to me that the TIME and BREACH
  attacks might apply to application-layer compression technologies
  such as XEP-0138 for XMPP. I haven't looked into that in detail
  yet, but I figured I'd raise the issue here for discussion.
 
 XEP-0138's context is to provide compression when TLS is not
 available. So it should not be used together with TLS, but the
 security considerations cover the case where both are used. Maybe
 better adjust these.

Prosody recommends disabling TLS compression and enabling XMPP compression
instead, citing high memory usage by OpenSSL for the latter. The intended goal
might have been to allow for compression without TLS, but that's not how it's
used in practice.

TLS compression is also more vulnerable to compression attacks as it covers
the SASL exchange too.


  Depends on what data you consider secret.
 
  Passwords shouldn't be in the compressed stream, per XEP-0170.
  Other highly sensitive data can be your contact list and the
  contents of your messages. Both of these an attacker should not be
  able to trigger retransmissions of, which complicates attacking
  them.
 
  But it's likely the attacker will be able to extract information
  like is jul...@example.lit on your roster?, did you receive a
  message from jul...@example.lit in the past 32 kB? (the zlib
  window size) or did you receive a message that included the phrase
  'thermonuclear war' in the last 32 kB?.
 
 Thijs, can you explain this a bit more? As far as I understand these
 attacks, they work when both a secret and data supplied by the
 attacker are in the same compression context. That has to be the same
 32 kB compression window (in the case of zlib). I don't see how the
 attacker can inject data into that, we don't have CSRF issues in XMPP.
 Or it has to be for contexts like the IOT, where sensors can be
 manipulated so you can test if the sensor has been sending the same
 value just before.

I'm making the following assumptions:

1) The attacker is able to route XMPP packets to the target (by a presence
subscription or by knowing their full JID).

2) The attacker is able to observe the length of the packets between the
server and the target's client.

Sure, if you're only considering scenarios where TLS isn't used then these
assumptions make no sense, because any MitM will have full read/write access
to the stream.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] compression attacks

[Thijs Alkemade]

On 13 feb. 2014, at 01:04, Peter Saint-Andre stpe...@stpeter.im wrote:

 While working on draft-sheffer-uta-tls-attacks with Yaron Sheffer this week, 
 he pointed out to me that the TIME and BREACH attacks might apply to 
 application-layer compression technologies such as XEP-0138 for XMPP. I 
 haven't looked into that in detail yet, but I figured I'd raise the issue 
 here for discussion.

Depends on what data you consider secret.

Passwords shouldn't be in the compressed stream, per XEP-0170. Other highly
sensitive data can be your contact list and the contents of your messages.
Both of these an attacker should not be able to trigger retransmissions of,
which complicates attacking them.

But it's likely the attacker will be able to extract information like is
jul...@example.lit on your roster?, did you receive a message from
jul...@example.lit in the past 32 kB? (the zlib window size) or did you
receive a message that included the phrase 'thermonuclear war' in the last 32
kB?.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] xmpp.net test SSL trust

[Thijs Alkemade]

On 6 feb. 2014, at 10:59, Daniele Ricci daniele.ath...@gmail.com wrote:

 I think I understand why... my server has no direct TLS port, just
 STARTTLS. Is the certificate tested via STARTTLS as well?

The fact that CAcert certificates are not penalized currently is simply
because it's running Debian, and Debian has CAcert in their trust anchors.

But I'm still a bit torn on whether to change this. I do think that outright
removing them and thereby giving every CAcert server out there an F would be
too harsh.

On the one hand, using CAcert probably means 99% of normal users won't
properly verify your certificate.

On the other hand, there are other alternative trust methods I want to
introduce, like POSH and DANE (already shown, but doesn't influence trust). If
I use the same argument of nobody's code will trust them based on this, then
those will probably keep getting an F for a long time. That's not very
stimulating.

So I'm thinking about reducing the score for servers relying on CAcert, DANE
or POSH to A- or B and showing a warning about it.

The test will only test StatTLS on port 5222/5269 or the port found in SRV
records. It will not try old-style SSL on port 5223.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Thijs Alkemade]

On 18 nov. 2013, at 23:49, Carlo v. Loesch c...@mail.symlynx.com wrote:

 On 11/18/2013 01:53 PM, Florian Zeitz wrote:
 On 18.11.2013 13:38, Steffen Larsen wrote:
 Well you can €œalways” run XMPP on top of TOR if you like that, if it is 
 the S2S routing that bothers you. :-)
 
 Not so simple.. S2S protocols expect you to have a well-defined domain name
 so it takes some tweaking to use a XXX.onion instead - especially if you'd
 like to have enhanced forward secrecy by embedding TLS: how the hell will
 you validate a .onion certificate? This would require a whole new XEP and
 a certification strategy to go with it.

Federating over hidden services requires some extra work, but it’s not that
hard. I’ve written a Prosody module for it, which can be found at [1]. Some
more background at [2].

Tor already offers forward secrecy, if I remember correctly it uses TLS with
EDH. Unless you want to assert a clearnet identity, I don't see the added
benefit of using TLS when accessing a hidden service.

For s2s, you have the same solution as with most servers currently: dialback.
.onion addresses being cryptographically verified makes this actually secure
in this case. This would work even when federating between hidden services and
normal XMPP servers (although the normal server needs Tor access, of course,
and the hidden service must keep in mind to always use Tor to dialback).

[1] = https://code.google.com/p/prosody-modules/wiki/mod_onions
[2] = 
https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-over-tor-hidden-services/

Re: [Standards] Dialback, authentication, and authorization

[Thijs Alkemade]

On 13 nov. 2013, at 12:56, Dave Cridland d...@cridland.net wrote:

 Then there's the same-cert shortcut, where the receiver connects to the 
 authoritative server and compares certs. This is an interesting case, because 
 we're deriving identity (and therefore authenticating) from the certificate, 
 but the certificate isn't sufficient to authorize - so we dialback to the 
 authoritative server and if the certificate matches, this is sufficient 
 authorization.
 
 What we're now debating is whether we need a trusted identity in same-cert, 
 or whether a self-signed certificate is sufficient. We need to be assured 
 that the identity is unique - that is, that the private key is known only to 
 the authorized party, basically, and I'm personally concerned that there 
 could be cases of TLS and/or XMPP implementations shipping with a sample 
 certificate then used in production.
 
 What do people think?
 
 Dave.

I’ve added a table to the xmpp.net stats page showing which domains share a
public key:

https://xmpp.net/reports.php#sharesprivatekeys

It checks the SPKI field, so the certificates may be different but the public
key on them is the same.

Of course many are harmless false positives, there might be good reasons why
two domains share a key. But those of note are:

Prosody's default key:
F7:D9:2E:68:43:43:A9:EA:2E:BE:5F:FA:4B:B7:B9:25:EC:3C:03:5B:85:B5:C4:38:48:0E:8A:9A:71:66:E6:E6

Ejabberd's default key:
C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE

Thijs

Re: [Standards] Dialback, authentication, and authorization

[Thijs Alkemade]

On 13 nov. 2013, at 14:51, Philipp Hancke fi...@goodadvice.pages.de wrote:

 Ejabberd's default key:
 C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE
 
 That is the CN=ejabberd? Likely the same one I saw back in
 http://mail.jabber.org/pipermail/standards/2007-July/016086.html

No, the CN of all results with that public key is “Mickael Remond”, see for
example https://xmpp.net/result.php?id=2179#certificates.

Thijs

[Standards] Proposal: Public Key pinning

[Thijs Alkemade]

Hello!

Reading [1], I thought it would be neat to have the same on XMPP.

The idea is that a server can pin the list of public keys that should be
trusted for future connections. These contain the CA's public key, the leaf
certificate's key or backup keys in case the current key is lost. This should
make it easier to secure servers that use self-signed certificates (especially
for s2s connections) and it can strengthen the security of servers that do use
CA issued certificates.

Of course, there are alternatives:

* DANE. DNSSEC deployment is still low and DANE is low compared to that. Few
DNS stacks include support for DNSSEC, so widespread DANE deployment is
unlikely to happen soon.

* SCRAM-SHA-1-PLUS can protect against MITM attacks by adversaries that don't
have the user's password, but this is not a solution that would work well for
s2s.

* TACK [2] generalizes key pinning to a TLS extension. But that means it's
probably also years away from actual deployment.

* XEP-0257. I don't think this XEP matches exactly, but it comes close and
could of course be adapted instead of introducing a new one.

Anyway, I thought a new extension would be better, so I wrote a proposal for
an extension which can be seen at [3]. It is meant to be an interim solution
until DANE gets wide adoption. The format of the pins follows [1] - but it can
also be seen as 2 1 1 or 3 1 1 TLSA records from DANE. In other words, much of
the code written to support this can be reused for DANE.

Any feedback on this proposal is very welcome. :)

Regards,
Thijs

[1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
[2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02
[3] = https://xnyhps.nl/~thijs/linked/prosody/xep-cert-pinning.html


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] XEP for facebook's receive messages you send from other clients ?

[Thijs Alkemade]

On 12 okt. 2013, at 12:11, Alexander Karelas wrote:

 When you're logged in to facebook.com, you see in your browser window
 all messages you send to your friends, even if you send them from other
 clients (like Pidgin or another browser tab)
 
 Is there a XEP about having all your clients receive your own messages?
 If not, are you thinking of making one? I need the same functionality on
 my website, and thought it would be much better to implement a standard
 XEP than do my own solution, which will be incompatible with future XMPP
 clients.
 
 Thanks,
 
 - Alex

http://xmpp.org/extensions/xep-0280.html.

Facebook does do the same on their XMPP gateway, but that's a custom extension 
not based on XEP 0280.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Thijs Alkemade]

On 20 jun. 2013, at 05:14, Peter Saint-Andre stpe...@stpeter.im wrote:

  
  So when we wrote XEP-0178 this was fairly vague, but the upshot
  is that it probably needs some revision:
  
  1) The right way to specify the jid you're expecting to become is
  by using the from attribute of the stream. This is most
  especially true for servers.
  
  I'm still not sure I understand 10(c), though. Does the address 
  specified during SASL negotiation refer to the from attribute on
  the stream?
 
 IMHO that would indeed be the 'from' on the initial stream header. It
 would be good to clear that up in the spec, eh?
 
 Peter

There's one more point I want to make about this, not exactly related, but close
enough to continue this thread.

The security considerations section of XEP-0178 states only:

This document introduces no security considerations or concerns above and
beyond those discussed in RFC 6120 and RFC 6125.

While that may be true, there's one thing that might warrant some emphasis:

Both the server's and the client's certificate are sent in plain during the
handshake. This means that any id-on-xmppAddr attribute, common name field or
any other personal info on the certificate will be visible to any passive
observer of the stream. Every client I've used tries to avoid leaking your
identity before TLS is active (no 'from' attribute on the initial stream) and
this could break that.

Even when a user is using a certificate with no personally identifiable
information at all, just by looking at the public key an observer could try to
correlate different connections to the same account.

In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation
as a way to protect the client's certificate if it's known to be private. I
guess this would work, though I'm not sure how well-supported that is.

I think it would be good if XEP-0178 at least mentioned that the certificate is
sent in plain and pointed to §5.1.3 for a workaround.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Thijs Alkemade]

On 14 jun. 2013, at 23:10, Dave Cridland wrote:

 On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade th...@xnyhps.nl wrote:
 I don't see any possible downside to the client always sending its desired
 authzid, except for maybe ~20 characters of extra data. The server can still
 do the same checking. I propose clients SHOULD send an authzid, except in case
 the certificate contains exactly one xmppAddr field, in which case they MAY
 omit the authzid and send =.
 
 Here's some history for you.
 
 Once upon a time, various people noticed that IMAP had only a simple LOGIN 
 command, and wanted to make a challenge-response based login. Because they 
 thought that maybe other ideas might come up in the future, they made a 
 generalized AUTHENTICATE command, which supported multiple mechanisms. This 
 is where SASL came from, and explains why many mechanisms are distinctly 
 text-flavoured (even though IMAP base64's them in order to handle those that 
 aren't).
 
 Some protocols - most notably Kerberos, but also Digest-MD5 - had an extra 
 slot aside from the login name, which was used for what's known as proxy 
 authentication - that is, logging in as someone else's proxy. It was 
 basically an assertion that this other guy was letting you login as them. So 
 you'd use your principal, or login name (now Authentication Identifier) and 
 password, but you'd ask to be logged in as somebody else - the Authorization 
 Identifier. Obviously if the same name was used in both places, this was the 
 same as not requesting Proxy Auth.
 
 As SASL became genericised for multiple protocols, this shifted slightly, and 
 two things happened:
 
 a) The Authorization Identifier became protocol-specific, whereas the 
 Authentication Identifier became mechanism-specific. In IMAP, this had made 
 little difference, as IMAP doesn't even have a native format, but for other 
 protocols, like XMPP and LDAP, it does.
 
 b) *Any* Authorization Identifier officially means you're trying to do Proxy 
 Auth.

Thanks for clearing that up, the lack of an authcid in this XEP confused me.

 So when we wrote XEP-0178 this was fairly vague, but the upshot is that it 
 probably needs some revision:
 
 1) The right way to specify the jid you're expecting to become is by using 
 the from attribute of the stream. This is most especially true for servers.

I'm still not sure I understand 10(c), though. Does the address specified 
during SASL negotiation refer to the from attribute on the stream?

Thijs

signature.asc
Description: Message signed with OpenPGP using GPGMail

[Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Thijs Alkemade]

Hello!

While working on XEP-0178 and XEP-0257 support, I noticed XEP-0178 makes the
distinction between 3 possible scenarios: the certificate contains one, more
than one or zero xmppAddr fields. Depending on the scenario and the authzid
the client wants to use the client must either include the authzid or use =.

This is the only reason the client would need to understand the certificate
for the user, which increases complexity for a client. The server still needs
to parse the certificate as well, as it needs to validate what the client
sends.

I don't see any possible downside to the client always sending its desired
authzid, except for maybe ~20 characters of extra data. The server can still
do the same checking. I propose clients SHOULD send an authzid, except in case
the certificate contains exactly one xmppAddr field, in which case they MAY
omit the authzid and send =.

Aside from this, I think the following line from 10(c) is self-contradictory:
only if it desires to be authorized as a JID other than the address specified
during SASL negotiation. This _is_ the SASL negotiation, unless I'm missing
something this is where an authcid needs to be sent. I don't understand where
the client would communicate its desired JID if it uses a certificate with
zero xmppAddr fields and sends =.

Regards,
Thijs

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] NEW: XEP-0313 (Message Archive Management)

[Thijs Alkemade]

On 25 mei 2012, at 13:52, Kevin Smith ke...@kismith.co.uk wrote:

 On Fri, May 25, 2012 at 12:42 PM, Thijs Alkemade th...@xnyhps.nl wrote:
 
 
 I've started implementing 0313 in libpurple/Adium, and I think
 Matthew explained my concerns quite well.
 
 Your suggestion assumes that once a client receives an incoming
 message from the server, everything the client sent before that
 moment was received by the server successfully (it makes sense to
 require Carbons to do MAM, but lets assume that Stream Management is
 not enabled). Suppose the last session ended with these two
 messages, on a high-latency connection which got interrupted:
 snip/
 
 If the client thinks message 12345 came before 9876, while the
 server thinks it's the other way around, then requesting the archive
 from abcde will duplicate message 12345.
 
 Yes. Always requesting based on the uid of the last message that you
 received will result in receiving from the server duplicates of any
 messages you have sent since then, and you'll have to not double-store
 them. 198 means that you know which of your sent stanzas have been
 processed by the server and does, I think, guarantee your history is
 complete and you're likely to end up, on average, with ~1 duplicated
 stanza to deal with on each login. The simple implementation is that
 you don't store in the cache anything that happened after the last
 message received from the server - and you know the ordering of your
 own stanzas vs the stanzas you received based on the ordering of the
 acks/messages you received from the server.
 
 /K

[Reviving a pretty old thread.]

I've been thinking about this a bit more recently. To summarize, the scenario I
mostly consider tricky is:

 * A user has a conversation on a wifi^H^H^H^Hbad connection.
 * At some point, the connection is lost. The client doesn't immediately
   notice, so the user sends n more messages before the client notices it's
   not connected anymore.
 * The client logs in again some time later.

How should it query the archive?

It can query based on the UID of the last archived / on an incoming message,
but then it will get its outgoing messages again. It can ignore the first n of
those outgoing messages, but not all might have arrived on the server. The
only comparison it can do is based on their contents or timestamps, both not
very unique or consistent. It can, as Kev suggested, not store the outgoing
messages until an incoming message is received, but I don't think users will
appreciate their archive being incomplete, even when we can't guarantee those
messages were actually received.

I propose this: outgoing messages don't only get a UID, but also some session
identifier. This SID stays the same for all outgoing messages during one login
and the client can obtain it from the server (using an iq at login, for
instance). For a client it becomes easy to see which of its messages from the
last session made it to the server (it can even flag those that never arrived)
and it can just request all those since the last known UID, ignoring all those
with the previous SID. An additional benefit is that it becomes easier to
group MAM messages by conversation.

This could even be done without support on the server: the client just adds a
tag to each message with a SID it generated itself. However, it can't verify
the SID is unique within the archive, it increases the size of every message
and it has no meaning for the recipient of the message.

I know the goal of XEP-0313 is to not get as complicated as XEP-0136, but in
my opinion the extra complexity makes it much easier to synchronize history
consistently. Clients can opt to ignore it, and for servers its just a little
extra logic to generate another identifier.

Regards,
Thijs

signature.asc
Description: Message signed with OpenPGP using GPGMail

[Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL

[Thijs Alkemade]

Hello list,

In order to make it easier to implement client-side certificates in 
Adium, I started on writing a module to implement XEP 0257: Client 
Certificate Management for SASL EXTERNAL in Prosody, which has since 
then been improved by Kim Alvefur. I have some comments about the 
XEP, which I would like to share.

- Example 5 and 6 have a typo: an erroneous / on line 4.

- It uses XEP 0189 to format the public keys. However, afaict it was 
written for version 0.8 of that specification, which differs a lot 
from the current version. I don't think the latest version suffices
(it appears to me it can only send the public key and some other 
meta-data such as begin and end time, not the full certificate). 
Theoretically, this is not a problem as everyone can look up the old 
version of the XEP, but in practice it might be very confusing and 
cause problems for developers who need to implement different 
versions of 0189.

- I'd like some clarification of the meaning of the name elements: 
The append element should contain a name and the keyinfo 
contains a different name, which according to 0189v0.8, should be 
th SHA1 hash of the certificate. Is the former name required to be 
unique? The examples suggest revocation and removal is done based on 
the latter name, but this is not explicitly noted.

- Related to the previous point, 0189v0.8 says that the x509cert 
element is optional, and only the fingerprint is required. While 
technically this is not a problem for 0257 (hash the client's 
certificate when it connects, and only compare that), I think this 
would have a lot of usability and security problems.

Taking the last 3 points together, I propose removing the link with 
0189, as that XEP seems to serve a different purpose now. All that 
is really necessary is to transmit the PEM encoded certificate, so 
the x509cert element could directly be inside the append element. 
The name in the keyinfo (which is actually a fingerprint) should 
either be removed completely (it adds no info) and therefore basing 
removing and revoking on the real name, or it should be renamed 
to something like fingerprint/hash/id and the XEP should be 
changed to explicitly note that removal/revocation is based on this 
value.

Additionally, I think it would be a nice enhancement to be able to 
check which online resources are using which client side certificate 
at a given moment, for example as part of the items / query 
result. Though maybe this is a bit too far outside the scope of 
this XEP.

Best regards,
Thijs Alkemade

Re: [Standards] NEW: XEP-0313 (Message Archive Management)

[Thijs Alkemade]

On 20 apr. 2012, at 10:32, Kevin Smith wrote:

 On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild mwi...@gmail.com wrote:
 One solution I came up with was for an entity that relays and archives
 messages to stamp the message with: archived by=capulet.lit
 id=1234-5678/ or archived by=conference.jabber.org
 id=8765-4321/. I'd be interested in feedback on this idea.
 
 Yes, we need (archiving, rather than stanza) ids stamped on the
 archived stanzas.
 
 However even archived/ doesn't cover the case of the client knowing
 the id of its *outgoing* messages. The server could echo them back
 with archived/... but then things start to get a bit muddy.
 The alternative is to not solve this, and clients should treat the MAM
 archive as the canonical source of history - (therefore fetching
 messages from the archive that have already been sent/received by it).
 A waste of bandwidth if nothing else.
 
 You will only need to request (assuming you have carbons) on average
 less than a single message that's a duplicate, though - as IM is
 typically send a message/receive a message [yes, there are exceptions
 where this is potentially very untrue], and you will have the id of
 the message you received.
 


I've started implementing 0313 in libpurple/Adium, and I think 
Matthew explained my concerns quite well.

Your suggestion assumes that once a client receives an incoming 
message from the server, everything the client sent before that 
moment was received by the server successfully (it makes sense to 
require Carbons to do MAM, but lets assume that Stream Management is 
not enabled). Suppose the last session ended with these two 
messages, on a high-latency connection which got interrupted:

C:
message id='12345' to='example.com'
bodyHello/body
/message

S:
message id='9876' from='example.com'
bodyHey/body
archived id='abcde' by='example.com' /
/message

If the client thinks message 12345 came before 9876, while the 
server thinks it's the other way around, then requesting the archive 
from abcde will duplicate message 12345.

On the other hand, if the client requests the archive starting from 
abcde and does not receive message 12345, it can not know for sure 
wether 12345 was even received by the server (the spec never 
mentions it, but in my opinion being able to mark a message as we 
thought this message was sent, but the server never got it is a 
necessary part of synchronizing your logs).

Not a typical case, sure, but also not something that is very 
unlikely to ever occur, and I think it's important to keep the 
client's logs as consistent as possible.

I don't really have a good solution to propose, though. Replying to 
every outgoing message with something that includes the UID it was 
logged with could work, but it might add quite a bit of overhead. 
Stream Management could help with the latter problem, but not the 
former.

Regards,
Thijs

Re: [Standards] MSN does XMPP

[Thijs Alkemade]

On 15 sep. 2011, at 12:05, Kim Alvefur wrote:

 connect but it requires X_MESSENGER_OAUTH2 sasl authentication.
 Is there docs on that somewhere yet?

It is explained pretty clearly in LiveConnectPrelim.chm, which you can find 
from http://dev.live.com (you probably need to sign up to access the technical 
preview).

I've been working on getting it to work in Adium, and it appears to be 
extremely similar to Facebook's OAuth2 mechanism (even their APIs are, to the 
point where I'm wondering their goal is to allow webmasters to change one URL 
to change from Facebook Connect to live.com).

Thijs

Re: [Standards] MSN does XMPP

[Thijs Alkemade]

On 15 sep. 2011, at 17:18, David Ammouial wrote:

 15/09/2011, Thijs:
 It is explained pretty clearly in LiveConnectPrelim.chm, which you
 can find from http://dev.live.com (you probably need to sign up to
 access the technical preview).
 
 Can anyone with access to that documentation please convert it to a
 readable format and make it public?
 
 Thanks!
 -- 
 David

https://xnyhps.nl/~thijs/LiveConnectPrelim.pdf

Links seem to be broken after converting it, but the XMPP code samples all
link to https://github.com/liveservices/LiveSDK/tree/master/XMPP-Samples,
which is still empty.

Thijs