Re: [Standards] Council Minutes 2019-12-04

[Evgeny]

On Wed, Dec 11, 2019 at 3:52 AM, Tedd Sterr  
wrote:
Dave notes this is unchanged since being rejected by the previous 
Council, and wants to avoid setting a precedent where an XEP is 
re-submitted unchanged until one Council eventually accepts it.


Just my few cents: I'm with Dave here. If it has been rejected by 
mistake, then something is unclear in the XEP and at least a 
clarification should be added before re-submission.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Bookmarks 2 extensibility

[Evgeny]

On Mon, Nov 25, 2019 at 5:25 PM, Dave Cridland  
wrote:
We put arbitrary namespaced data inside messages and other stanzas 
all the time to no ill effect. Why is putting it inside PEP data 
items so different?


Because I like the approach used when designing ASN.1 schemas (see for 
example RFC 5280 (PKIX) or, more simple, RFC 6960 (OCSP)), where you 
define "extensions" fields explicitly. And in the case of 'message' 
stanzas we kinda have implicit assumption that this stanza has such 
"extensions" field where we put whatever we need (speaking in ASN.1 
approach).


So actually I like the suggestion of Emmanuel with extensions element.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Bookmarks 2 extensibility

[Evgeny]

On Mon, Nov 25, 2019 at 5:17 PM, Dave Cridland  
wrote:
If you're saying we shouldn't have arbitrary namespaced data in such 
places, I disagree.


Yes, I see that we disagree. Dead end like always.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Bookmarks 2 extensibility

[Evgeny]

On Mon, Nov 25, 2019 at 4:47 PM, Philipp Hörist  
wrote:
From a programming perspective I would argue that storing one element 
away is much less work than searching for all unknown child elements.


+1. I also disagree with what Jonas and Dave said: we should not abuse 
extensibility by putting any element inside any other element. I think 
semantics matters here and children elements should be somehow related 
to their parents elements, even though the namespace is different.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

[Evgeny]

Oops, sorry, wrong thread. I was mentioning XEP-0402 (Bookmarks 2) of 
course.


On Wed, Nov 6, 2019 at 8:53 AM, Evgeny  wrote:

...


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

[Evgeny]

On Wed, Oct 23, 2019 at 9:41 PM, Paul Schaub  
wrote:

1. Is this specification needed to fill gaps in the XMPP protocol
 stack or to clarify an existing protocol?

 2. Does the specification solve the problem stated in the 
introduction

 and requirements?


The purpose of the XEP is unclear. The only mentioned "advantage" is 
that it allows to publish multiple "items". And?



 3. Do you plan to implement this specification in your code? If not,
 why not?


No. Because I see no reason to introduce 3rd version of bookmarks and 
breaking compatibility without clear benefits.



 4. Do you have any security concerns related to this specification?


No.



 5. Is the specification accurate and clearly written?


Seems so.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0423 (XMPP Compliance Suites 2020)

[Evgeny]

On Tue, Oct 15, 2019 at 9:27 PM, Marvin W  wrote:

IMO XEPs should never mandate anything on UI.


Mandating - no. But you can find lots of SHOULDs in different RFCs, for 
example when talking about errors displaying in user agents. Seems like 
it's becoming a common practice...


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Thu, Oct 10, 2019 at 11:20 AM, JC Brand  wrote:

Now you're saying "limitation", previously you said "restriction".


I use those words interchangeably in this context.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Thu, Oct 10, 2019 at 10:59 AM, JC Brand  wrote:
Well, to come back to Georg's point of not deprecating BOSH until we 
have a
solution, it seems that XEP-0397 would need to be included in the 
compliance
suite, at least for this particular use-case (maintaining anonymous 
logins

over websocket).


Well, as I already said, the issue with anonymous logins and XEP-0198 
resumption already exists for "normal" TCP/TLS c2s connections. It's 
unrelated to websockets.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Thu, Oct 10, 2019 at 10:52 AM, JC Brand  wrote:

You're arguing against a point nobody made.

Nobody advocated using BOSH to bypass restrictions in XEP-0198.
The issue Georg mentioned isn't due to anything in XEP-0198.

The issue is with the SASL anonymous login mechanism not allowing you 
to
reconnect with the same JID, which happens **before** trying to 
resume a

XEP-0198 session.


The issue is *exactly* due to limitation in XEP-0198 that you're trying 
to bypass with BOSH: since XEP-0198 doesn't allow you to resume a 
session without re-authentication (and with SASL ANONYMOUS you cannot 
re-authenticate with the same JID), you resort to use BOSH to bypass 
this restriction, since it's *implicitly* using session identifiers as 
authentication tokens.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 6:07 PM, Evgeny  wrote:

supporting both XEP-0198 and BOSH makes no sense at all


I would also add that implementing both XEP-0198 and BOSH in the server 
is not a trivial task at all. I would say both are very complex to 
implement correctly and have tons of caveats. So by 
recommending/requiring both in the compliance suite the Council needs 
clearly understand what burden this puts on server developers. Just my 
few cents.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 10:20 PM, Evgeny  wrote:
I still doubt this is anyhow more secure than session resumption in 
XEP-0198 (which btw requires real re-authentication).


Let me explain: using BOSH to bypass restriction of XEP-0198 (namely, 
SASL re-authentication) doesn't justify usage of BOSH, in my opinion. 
Such explanation looks really weird, to say the least.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 10:11 PM, JC Brand  wrote:
"Restoring" a session means simply making a new request within the 
timeout

period. Whether the browser tab has been reloaded in the meantime is
irrelevant.


I still doubt this is anyhow more secure than session resumption in 
XEP-0198 (which btw requires real re-authentication).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 6:27 PM, Evgeny  wrote:
According to such logic this "problem" should be resolved for plain 
TCP c2s as well. Unless it's not solved we should not kill BOSH.


Ah, and another question is raising: why actually BOSH allows you to 
restore the session without re-authentication, when XEP-0198 doesn't? 
Is BOSH a more secure transport?


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 6:24 PM, Georg Lukas  wrote:

Until this problem is solved, I'd rather not kill BOSH.


According to such logic this "problem" should be resolved for plain TCP 
c2s as well. Unless it's not solved we should not kill BOSH.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

[Evgeny]

On Wed, Oct 9, 2019 at 5:56 PM, Jonas Schäfer  
wrote:
- Should we really require both BOSH and WebSockets for the Web Suite 
for
clients? Maybe it makes more sense to require it both for Servers, 
but only
one of them for clients, possibly even phasing out BOSH. (Disclaimer: 
I’m not

a Web person).


I would like to see BOSH dropped and moving the XEP to historical or 
deprecated state, because I see zero advantages over Websockets now 
(supporting both XEP-0198 and BOSH makes no sense at all).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Ephemeral messages to offline users (XEP-0085, XEP-0160?)

[Evgeny]

On Thu, Jun 6, 2019 at 12:45 PM, Daniel Gultsch  
wrote:

I never liked the behaviour of some clients that would simply show
error messages without any context whatsoever in the chat window.
I prefer clients that track actual messages and mark individual
messages as failed.


That's a typical pitfall of a developer who doesn't treat errors as 
first-class citizens, despite research routinely demonstrates that 
ignoring error conditions in application leads to major bugs and error 
processing code is typically buggy (in particular, in server segment 
those are the #1 reason of a service outage). I don't see how putting 
the burden on servers will improve the situation: it will not make 
client development simplier, it will just encourage a bad programming 
pattern.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0260 (jingle socks5 transport) candidate-complete event

[Evgeny]

On Mon, Apr 29, 2019 at 6:05 PM, Daniel Gultsch  
wrote:

how about sending the upnp as a fallback using transport-replace, with
a new transport (new id) of type s5b:1?


Guys, how about switching to TURN instead? Maybe it's time already? ICE 
is not something new anymore. You will really benefit from the code in 
the future if you decide to support some sort of VoIP.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 10, 2019 at 1:43 PM, Melvin Keskin  wrote:

But end-to-end encryption is about sending encrypted messages from one
secure endpoint to another secure endpoint. It is not about securing
the endpoints themselves. If an endpoint is compromised, no end-to-end
encryption can help.


Encryption won't help, but you should still be able to revoke a 
compromised key. Also, your proposal is not about encryption, so such 
things should be addressed.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)

[Evgeny]

On Sat, Apr 6, 2019 at 5:59 PM, Jonas Schäfer  
wrote:
I agree with Florian fully. This is rather non-idiomatic to implement 
on the
client side, due to how XMPP works otherwise. The flow suggested by 
Florian is

more idiomatic and implementable with less brain-hurt.

I don’t see any advantage (only disadvantages) on the client side 
with the
message based flow (also, the horrors of carbons and archives), and 
I’m not

sure which advantages there would be for servers.


No problem, I will re-design the flow, this is absolutely not a subject 
for debates for me.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposal: Re-Design of the XEP HTML Pages

[Evgeny]

On Sat, Apr 6, 2019 at 12:59 PM, Jonas Schäfer  
wrote:
I integrated more feedback and after lots of folks shouting "SHIP IT" 
at me
and it haunting me in my dreams (not really), I decided to give it a 
shot.


Is it possible to render full author's name in the version history?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 6:02 PM, Melvin Keskin  wrote:
I appreciate that you think of UX aspects but ATT should not degrade 
UX
when another way of authentication is implemented alongside it. For 
ATT

no user interaction is needed and it can always be used. It is not
necessary to deactivate it. It can just be extended by other
mechanisms covering other cases.


The problem is that ATT resolves the same problem as EAX does (by 
putting the burden on CAs). So we have two conflicting approaches.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 5:52 PM, Melvin Keskin  wrote:

Every way has its advantages and its disadvantages.


Everything is relative, I see.


That was the reason for creating ATT. I
wanted the users to benefit from automating the whole process of key
authentication now and not some day in the future. If we only
concentrate on the future, we will forget the problems current XMPP
users are facing nowadays.


And I kinda want to adopt EAX in the next century? I'm not going into 
ranting about "I need it ASAP" mentality in standards development, but 
with such approach, can you please address a potential problem of 
compatibility when some clients support EAX and some manual-only 
verification with ATT?


> My main focus are new XMPP users. It was> hard for me to get them to 
XMPP and we will lose them again if we do

> not provide solutions for current problems.

I don't see an urgent problem here, but okay.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 5:06 PM, Melvin Keskin  wrote:

ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.


I already replied: if we produce both XEPs, we'll end up with some 
devices with manual/ATT verification and others with EAX. This will 
further degrade UX. So the XEPs interaction is required to be 
documented.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 4:54 PM, Melvin Keskin  wrote:

Hello Evgeny,

thanks for your comments.


Hi, Melvin!


 This is especially doubtful,
 since it's speculated that the topology of a social graph has power-
 law
 distribution [1] and thus only a few people will benefit from the
 "trust transfer".


What exactly do mean by that?


I kinda misread your proposal, so it's irrelevant in the context of the 
proposal, sorry for confusion.



Using Certificate Authorities (CA) for key authentication would be
better than not authenticating keys at all. It could be used
additionally to the authentication of keys via ATT when you have no
other trusted channel to a contact.
ATT is completely independent of CAs. One advantage is that a user do
not have to decide which CA is trustworthy and which not. If one CA
trusts a contact's key and another not, the question "which CA should
the user trust?" comes up. Besides some other advantages that is a
problem ATT solves for the case when there is an already trusted
channel like a meeting in person.
In the case of own devices the user normally has such a trusted 
channel

to manually authenticate the keys of those devices (e.g., by scanning
their QR codes containing the fingerprint of the device's key). Thus, 
a

CA will never be necessary.

ATT does not exclude other ways of authentication. A combination of
more ways than that would be great to simplify the usage of end-to-
encrypted communication with authenticated keys.


Well, I understand all this. However, a complete picture I see is 
CA-signed certificates by default, and ATT and/or manual verification 
when you need more rigid authentication. So my suggestion is to stop 
taking positions (whether CAs are bad or whether manual verification is 
usable for regular users) and create a more general "framework". I also 
would like to note that MLS supports both ways. And, yeah, I see how 
ATT can improve UX as well (in theory).



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)

[Evgeny]

On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus  
wrote:
I am a little bit worried that this will take a few detours to 
implement

cleanly and elegant in clients and client libraries. Especially since
this pattern never occurred before.

Instead I suggest the following control flow, which should be straight
forward to implement with the facilities libraries currently provide:


Hi, Florian, thanks for your feedback.
Interestingly, in my very rough version I had exactly this scheme, and 
I found no real advantage. Instead, I made it possible to just resend 
the request (with the same CertificateRequest structure) if a client 
believes the challenge is resolved. What "detours" do you see possible 
from a client developer perspective?


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Evgeny]

On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub  
wrote:

There was a ton of
interesting discussions around OMEMO and other stuff, as well as some
productive coding (and Mate!).


Not to bash the ProtoXEP itself, but why the community constantly 
discussing OMEMO (and sometimes PGP), when there is ongoing work on MLS 
which will most likely be the standard e2e encryption? You also didn't 
mention MLS in your ProtoXEP at all.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX Implementation (Prosody module)

[Evgeny]

On Mon, Apr 1, 2019 at 12:03 PM, Tedd Sterr  
wrote:

somewhat working MIX implementation!


Apr 1 :/

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Fri, Mar 29, 2019 at 5:08 PM, Dave Cridland  
wrote:


In Winfried's case, he attended the 2016 FOSDEM key signing event 
where someone turned up with a specimen passport, and all but 20 
people signed his key anyway since they naturally assumed that nobody 
would be doing that. Winfried was quite upset at the time, which is 
understandable, but I still can't stop laughing.


Well in this case we don't have a trusted channel at all. Dead end.

Nor am I - it requires proper cryptographers, who are working on 
these problems at the IETF anyway.


Yeah, dead end again.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland  
wrote:


That's interesting, because my understanding was that the result of 
ATT was that if I manually verify one of your keys, I could then 
transitively trust all of your keys - I didn't read this as being 
that I might trust any third party keys.


Yes, I already corrected myself in the previous mail, sorry for 
confusion.


Indeed, I consider this to be essentially a channel binding problem 
where we implicitly trust the "in person" channel - I think Winfried 
might have a story to tell on why that can be a fallacious assumption.


What exactly is a fallacious assumption?

I think you can (somewhat) combine them in the way that MLS does, 
where each person has an identity key which signs each device key, 
and that identity key can then be manually, WoT, or CA verified as 
the users desire.


I'm simply not competent enough to resolve this, I'm working on CA 
protocol in my XEP.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Fri, Mar 29, 2019 at 4:07 PM, Evgeny  wrote:
1) The "trusted" graph is not connected (i.e. you cannot reach any 
vertex from any other vertex), thus, in the worst case the complexity 
of verification will remain the same. This is especially doubtful, 
since it's speculated that the topology of a social graph has 
power-law distribution [1] and thus only a few people will benefit 
from the "trust transfer".


Okay, I was corrected by Maxime: the XEP only addresses automatic 
verification of user's devices, so the context is even less narrow than 
I thought. Seems like 2nd bullet is irrelevant as well - the XEP 
doesn't address this at all. So, can we address 3nd point? This is a 
problem for me: if we accept ATT then I can remove CA coordination 
(which is even better for me), however, I have to require ATT support 
in this case. If the Council accepts both XEPs as is, then we raise 
inconsistency in our XEPs.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland  
wrote:
Overall, my view is that this specification is very unclear and 
impossible to implement as written.


I don't understand how this will work in practice indeed.
1) The "trusted" graph is not connected (i.e. you cannot reach any 
vertex from any other vertex), thus, in the worst case the complexity 
of verification will remain the same. This is especially doubtful, 
since it's speculated that the topology of a social graph has power-law 
distribution [1] and thus only a few people will benefit from the 
"trust transfer".
2) The problem of manual verification is still unresolved, because for 
online persons (i.e. without meeting them offline) you have to use an 
already trusted channel to perform verification, so chicken and egg 
problem.
3) Isn't it better to work on the problem together, i.e. in the context 
of my EAX proposals? If you don't trust the CA or want to have 
additional guarantees you can resort to manual or ATT verification. I 
don't see any contradictions here. Both approaches are kinda 
complementary and can be working together, unless you're reluctant and 
hate CAs.


[1] https://en.wikipedia.org/wiki/Scale-free_network#Examples

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Evgeny]

On Thu, Mar 28, 2019 at 12:41 PM, Philipp Hörist  
wrote:
I saw no arguments against 0394 and its approach, as i see it 
perfectly fits Andrews usecases.
I dont see that there is a need to enclose each markup element into 
reference elements just for the sake of consistency. This would lead 
to some horrible inefficient syntax. I think developers can deal with 
the syntax that is described in 0394, they will not give up because 
they dont find a reference element.


I'm not a client developer, but technically I tend to think that 
XEP-0394 is way superior because you get ready to use AST attached to 
the text, so you don't even need to parse anything.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Evgeny]

On Wed, Mar 27, 2019 at 11:17 PM, carlo von lynX  
wrote:

XMPP will be nearly completely dead in coming years
as it has always refused to change the fundament of its
inflexibility


Hey, dude, how is your psyced going? Oh, it's dead. Okay.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-17

[Evgeny]

Hey, Georg, Dave.

I think I have addressed all your concerns in my new local copy [1]

[1] http://upload.zinid.ru/xep-eax-cir.html

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-17

[Evgeny]

On Fri, Mar 22, 2019 at 2:18 PM, Dave Cridland  
wrote:


You can just have a note somewhere that says "All examples, and much 
the the terminology, assumes that a CA is hosted on a XMPP server 
entity addressed by a domain-style Jid; this is not a requirement of 
the protocol, and a CA MAY be addressed by any valid Jid, including 
local@domain or even local@domain/resource."


Sounds good. Except I don't like the idea of a resource. I think it's 
something volatile and is attached to a session or a device, but not to 
a long living thing such as a CA certificate. Well, I cannot imagine 
any benefits from hardcoding the resource, only drawbacks (e.g. a 
server can easily change it, and an operator may only detect this after 
software upgrade). This also will not make it possible to run several 
bots on the same JID (for load balancing for example).


Yes, I hadn't actually noticed you'd said "PEM without headers". I'd 
prefer specifying just base64 DER. While these are the same thing in 
principle, I think it clarifies things enormously.


Fine by me.


Timeouts during a challenge procedure is indeed a problem. However, I
don't see how this can be overcome by using data forms or other
stanzas. I think a client should render "Cancel" button when it has 
run

an URL handler and wait indefinitely. And yes, the complexity.



I did wonder, actually, about seperating the CSR submission from the 
processing.


The spec as written more or less assumes a short, online interaction 
- if you assume lots of manual intervention and an offline CA, I 
think this becomes rapidly impractical.


What about an IQ which creates the signing request with a CSR, and 
returns an id which can be queried about status? The query could 
trigger resending any pending challenges, too, as well as delivering 
the certificate.


I think current protocol supports all these. CSR itself already plays a 
role of the id: a client may resend a request and the server will 
respond with a certificate if it has already issued it for this exact 
CertificateRequest structure (without even challenging a client). And 
the structure is required to be retained until successful completion of 
a transaciton. See "Mobile OS Considerations" section [1] as an example 
of how this can be used.



Probably it's not, I can remove it. It has left from the previous
version of the document.



I'd drop it to a SHOULD rather than removing it. It's always useful 
to know whose error it is.


Hehe, too late, I already removed it and made other changes :)
Also, this is a very general advice that doesn't belong solely to this 
particular specification.


[1] http://upload.zinid.ru/xep-eax-cir.html#mobile-os-cons

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-17

[Evgeny]

On Fri, Mar 22, 2019 at 11:29 AM, Georg Lukas  wrote:

* Tedd Sterr  [2019-03-17 21:53]:
 Proposed XMPP Extension: E2E Authentication in XMPP: Certificate 
Issuance and Revocation - 
https://xmpp.org/extensions/inbox/eax-cir.html


+1


Thank you very much for the thorough review.



- A CA doesn't _need to_ be a server entity. It's well possible for a 
CA

  to be a bot@domain/resource or a component.domain, as long as it's
  ensured that the respective server is configured to enforce s2s (and
  c2s) TLS and to check server certificates.


I was thinking about this. The terminology in the XEP becomes more 
complex. How to name this stuff? CA XMPP entity? But this is a cosmetic 
issue of course.




- I'm not sure what is gained by stripping the PEM BEGIN/END headers.
  IMO It's not worth optimizing for two lines at the cost of increased
  client and server complexity.


Without PEM encapsulation boundaries it's just a Base64 encoded DER 
stuff. So you can use Base64 codec for this, not full blown PEM codec 
which should parse and understand the boundaries and which can run into 
compatibility problems (due to historic reasons outlined in RFC7468). 
Also, in other places, such as the signature element, it's just base64 
encoded binary, so we will run into consistency problems, although 
cosmetic, but still.


I can probably just to reform the phrase and say that it's Base64 
encoded DER ASN.1 stuff. Note also, that understanding full PEM
encoding is not required by the document (all those places are SHOULD 
or RECOMMENDED or some such).




- Signing Request: I'm not very happy with using IQs for the request 
and
  response, because there is an optional message-based manual 
challenge
  step in between, essentially meaning that the IQ request must be 
sent

  with an infinite timeout. OTOH, replacing this flow with something
  like data forms / ad-hoc commands might make things even more 
complex.


Timeouts during a challenge procedure is indeed a problem. However, I 
don't see how this can be overcome by using data forms or other 
stanzas. I think a client should render "Cancel" button when it has run 
an URL handler and wait indefinitely. And yes, the complexity.




- Is there a specific reason for mandating the @by in the error
  response, in addition to the IQ @from?


Probably it's not, I can remove it. It has left from the previous 
version of the document.




- §8.1: it should be explicitly stated that this part replaces the
  XEP-0077 IBR workflow and not extends it. Also that by using this
  mechanism, the account does not have a password and that the only 
way

  to register another device is to copy over the private key.


In recent version of the document [1] (which is only a local copy that 
I'm going to submit later) I address this problem and X.509 IBR can be 
used to recover access to the account without copying keys.

And yes, I can add the statement.



- §9: 'id' attribute of the  element MUST contain first 16 
octets
  from a signatureValue" - if this is required for interop, it should 
be

  "MUST equal to", otherwise it might as well allow shorter @ids, eg.
  urls-safe-base64.


Okay, whatever. I don't oppose, I'll change it. Although I personally 
don't see the difference, probably it's lost in translation.


[1] http://upload.zinid.ru/xep-eax-cir.html#acc-recovery



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Evgeny]

On Tue, Mar 12, 2019 at 11:08 PM, Jonas Schäfer  
wrote:

This specification defines an XMPP protocol extension for sending DNS
queries and getting DNS responses over XML streams. Each DNS query-
response pair is mapped into an IQ exchange.


Is this supposed to be an April 1st joke?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 8:35 PM, Daniele Ricci 
 wrote:

Did I lose the email by Wiktor? Or did he replied to you only?


https://mail.jabber.org/pipermail/standards/2019-March/035859.html

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 8:17 PM, Evgeny  wrote:
Yeah, my protoXEP allows for instant certificate issuance without 
challenges [1]


Oops, forgot the link: 
http://upload.zinid.ru/xep-eax-cir.html#cert-issuance


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 2:33 PM, Wiktor Kwapisiewicz 
 wrote:
Issuing this certificates can also be automated, just like certbot 
does for Let's Encrypt. This would work in backwards compatible way, 
so for everyone that don't want to opt-in to this scheme a regular 
captcha would be shown. But for everyone that uses the scheme the 
experience would be better.


Hello, thanks for your input.

Yeah, my protoXEP allows for instant certificate issuance without 
challenges [1]
And we can probably have different kinds of CAs or some X.509 extension 
to indicate how strict the certificate challenge was.
Probably we can have also tokens (as long as they are trusted) or 
something for anonymous messaging too, but I'm not competent in this, 
so cannot comment.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] EAX

[Evgeny]

Hi, standard people!

So I'm going to propose my third (and last) protoXEP [1] in EAX series 
[2][3][4].
Since the editor is kinda busy these weeks, I'd like the Council to add 
it to the upcoming agenda, since it's empty anyway :)
I see here and there some confusion on WTF I'm actually doing, so here 
is a brief summary.


It's actually not about RELOAD. The idea is to build Public Key 
Infrastructure (PKIX) based on X.509 certificates which is supposed to 
be used in c2s SASL EXTERNAL and end-to-end authentication. So yeah, I 
suggest to severely redesign authentication in the Jabber network and 
move towards more p2p-ish architecture: will it be RELOAD or some kind 
of roaming user profiles, doesn't matter that much, the point is to 
slowly get rid of federation because it's a dead end in my opinion. In 
particular, I suggest to eliminate SASL SCRAM family (it just sucks, 
see my previous rants regarding SCRAM in this list and in the XSF 
conference). The main problem was actually how to issue certificates 
for XMPP clients. This is now specified in details in my last protoXEP 
[1]. Note that the protoXEP also introduces new in-band registration 
method: creating an account and issuing a certificate in a single step. 
Ah, and this global authentication stuff is supposed to rely on a few 
central fragile CA servers because we all love CAs :)


The use cases are outlined in XEP-0416 [2], but since nobody reads 
intros, I'll copy them here (slightly modified):


1. E2E encryption
=
For end-to-end encryption, XMPP clients may use certificates to 
mutually identify each other, i.e. check that the cryptographic key 
belongs to this exact XMPP address. This is supposed to resolve "verify 
my OMEMO fingerprint" insanity we have today.


2. External services

An XMPP server may authenticate users of other servers at its local 
services, such as an HTTP Upload component, e.g. for granting file 
uploads, or a STUN/TURN/SIP server. This is supposed to resolve 
authentication on external services and provide an ability for clients 
of abandoned servers to use services from other servers. In fact 
anything that supports TLS may authenticate users using certs.


3. XMPP Usage of RELOAD
===
XMPP entities attached to the XOR overlay (XEP-0415 [3]) are supposed 
to use certificates for mutual authentication. This is too complex and 
somewhat unfinished, I'll address it later.


4. SPAM protection
==
Since certificate authorities are required to be Sybil resistant [4], a 
spammer is limited in ability to create accounts massively. Thus it is 
expected that SPAM dissemination will fall to negligible levels. This 
one is quite straightforward: let's finally eliminate SPAM. This time 
for real.


5. Registration delegation
==
Managing freely available account registration at public servers is not 
a simple task for operators of these servers. Failing to manage it 
correctly leads to uncontrolled massive creation of accounts used for 
SPAM propagation, DoS attacks, etc. and degrades the Jabber network as 
a whole. A server operator may want to delegate a registration and 
verification procedure to a trusted CA, which is supposed to be very 
good at this task. The operator doesn't lose the userbase in this case: 
user data and profiles are still located at the operator's server 
(although I'm personally against siloing users for the sake of siloing 
users).


6. Moved

The certificates can be used for e2e authentication needed during 
moving an account from one server to another and it doesn't rely on any 
support from the server a user is moving from. At least that's what I'm 
told :)



Comments, criticism and hating are welcome! But before you're gonna 
hating and ranting how bad CAs are (it actually depends on us in this 
case), please provide alternatives for the outlined problems without 
pretending those problems don't exist :)


[1] http://upload.zinid.ru/xep-eax-cir.html
[2] https://xmpp.org/extensions/xep-0416.html
[3] https://xmpp.org/extensions/xep-0415.html
[4] https://xmpp.org/extensions/inbox/eax-car.html#ca-reqs

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Third month with no updated compliance suites

[Evgeny]

On Mon, Mar 4, 2019 at 7:42 AM, Ненахов Андрей 
 wrote:
I think that the whole idea of making compliance suites as a xep is 
flawed and creates unnecessary bureaucracy for bureaucracy sake.


It could have been just a page on xmpp.org website, listing XEPs that 
council currently consideres part of a compliance suites. No 
bureaucracy, no need to update them every year, win-win for everyone.


If someone won't be happy with just a current list, well, add 
versions to it, in the simplest way possible.


Honestly, sounds like yet another bikeshedding to me. That's not me or 
you who deals with the bureaucracy and if the folks from the Council 
want to do the bureaucracy, let them having fun with it.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Let us zap master passwords from devices

[Evgeny]

On Thu, Feb 14, 2019 at 2:20 PM, Wiktor Kwapisiewicz 
 wrote:
SASL EXTERNAL has some practical issues, like client certs being sent 
in cleartext [1] and the fact that for example Android requires lock 
screen to be on to add client certs to the store not to mention 
problems in browsers (browsers generally can do client certs but I'm 
not sure if any XMPP server would do client cert handshake over 
websockets).


[1] is solved via ESNI extension (IETF I-D in progress)
[2] you can use your own certificate storage without relying on Android 
library
and w.r.t Web clients: adopting XMMP servers implementation is the 
least of the problems.


I strongly advice to go a well-established certificate way without 
re-inventing wheels just to solve momentary up-to-the-minute problems.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM-SHA-1-PLUS and Browsers

[Evgeny]

On Fri, Feb 8, 2019 at 9:23 AM, Marcel Waldvogel 
 wrote:
I just became aware that XEP-0412/RFC 6120 mandate SCRAM-SHA-1-PLUS. 
The way I understand it, the required TLS Channel Binding for the 
SASL -PLUS schemes is not possible from browser-based clients, as 
there is no way to get at the required low-level TLS information.


Yes, the -PLUS extension is just an abstraction leakage, and current 
use cases (browsers, load-balancers, etc) clearly reveal it. I myself 
don't like the tendency how TLS is leaking into upper application 
layers more and more (SNI, ALPN and now various IDs).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2019-02-06

[Evgeny]

On Tue, Feb 5, 2019 at 7:58 PM, Dave Cridland  wrote:

Meetings are normally held every Wednesday at 1600 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom.


s2s with the server doesn't work for me.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL MTI

[Evgeny]

On Fri, Jan 25, 2019 at 1:45 PM, Dave Cridland  
wrote:
I'm hearing "no", here - which is fine - but I do have a design for 
enforced password changes and password resets, too. The former is 
built around SASL2 (XEP-0388) and was actually one of the original 
design goals. Password resets we built at Surevine as a SASL 
mechanism (which we used with SASL2, but it'd work with the existing 
SASL profile in RFC 6120 as well).


1) I already criticized SASL2 back then for unnecessary complexity.
2) SASL2 still exists on the paper only without wide adoption.
3) I'm not sure every operator will be fine with the solution to force 
users changing passwords. I use a lot of services and I'm having hard 
time remembering any service doing this so far. Should we ignore this 
common practice?
4) What about situation with -PLUS variants? What's the answer to above 
Daniel's question related to TLSv1.3? Will we have problems with 
TLSv1.4?
4) I actually described several problems with SCRAM, and I did that for 
a reason, but seems like only those related to SHA upgrades are 
addressed (on the paper only BTW). What about potential downgrade 
attacks (including false positives)? Is it clear for all developers? 
For example, for me it's not that obvious what exactly to treat as a 
downgrade attack. What about interop with other services? What about 
performance degradation when SASL PLAIN is used with SCRAM'ed 
passwords? We already have "avalanche problem" caused by server 
restarts, and SASL PLAIN + SCRAM'ed passwords only worsen it. Also, if 
an attacker harvests enough JIDs it may successfully perform DDoS 
against the server forcing it to compute HMACs at a high rate.



I personally prefer:
1) MUST for EXTERNAL and PLAIN
2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all
   given all the problems I have described in another thread)


I'm hearing "yes" here, however.

Would you be interested in updating the MTI?


No. I don't have neither time nor desire to fiddle with IETF 
bureaucracy. Furthermore, that's not me who put SCRAM in the RFC. Also, 
we require SCRAM-SHA1-PLUS for years now, but still not every server or 
client implement it (typically only SCRAM-SHA1 is implemented). And 
seems like nobody gives a f*** for the RFC requirement. For me simple 
wiki page with clarifications and provided solutions is enough.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL MTI

[Evgeny]

On Fri, Jan 25, 2019 at 12:39 AM, Jonas Schäfer  
wrote:
My understanding is that Dave talks about Mandatory To Implement, 
which is
something different than Mandatory To Deploy / Mandatory To Offer (at 
least

that’s what I get from reading the relevant section in RFC 6120).


I think this is false dichotomy. But let's say it's ok. We still can
see negative outcomes of our decisions and try do our best to prevent
operators from running non-interoperable systems (and the system
without mandatory SASL mechanisms will not be interoperable, otherwise,
why would we need them to be mandatory?). To make sure, I clarify my
previous preferred MTI mechanisms (taking into consideration what Ivan
said above)

For servers: MUST for PLAIN, SHOULD for EXTERNAL and SCRAMs
For clients: MUST for PLAIN and EXTERNAL, SHOULD for SCRAMs

In this case our MTI will meet operator's needs and will prevent
potential interop problems with SCRAM.



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL MTI

[Evgeny]

On Thu, Jan 24, 2019 at 9:15 PM, Dave Cridland  
wrote:
XMPP-Grid (that draft) essentially says both servers and clients MUST 
implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and 
SCRAM-SHA-256-PLUS.


Is there any interest in updating our MTI?


How can we require SHA-256 when we don't have any way to upgrade
existing deployments from SHA-1? Leaving the burden to the operators
again, because this is out of scope of XSF? :)
Some already suggested "solving" this by forcing password
renewal, but we don't have any mechanisms to do this in XMPP.

I personally prefer:
1) MUST for EXTERNAL and PLAIN
2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all
  given all the problems I have described in another thread)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:46 PM, Jonas Schäfer  
wrote:
For stuff like TURN/STUN/... I would suggest to investigate the 
possibility of
tokens for user authentication (which cannot be used to log into the 
XMPP
service). I think I’ve seen such an implementation of a 
STUN/TURN/XMPP setup

in the past, but I can’t remember where.


I'm actually coming to conclusion that using SASL EXTERNAL is a better
approach to address all those issues with SCRAM:
1) You don't keep user credentials on the server
2) A user is absolutely sure the server doesn't store the credentials
3) I'm not aware of any interop problems, well, maybe with elliptic 
certs,

  but this is resolved by server upgrades (while supporting new
  SHA cannot be resolved by a server upgrade only)
4) Any external service supporting TLS (such as TURN or SIP) is able
  to authenticate you

The drawback is that client implementing this typically has
terrible UX, but this can be resolved IMHO (unlike SCRAM).

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus  
wrote:

I am not sure if the XSF is the right venue


Well, some people cite RFC 6120, as I understand, section 13.8.1,
which requires, among others, to support SCRAM-SHA1-PLUS. So
XSF responsibility cannot be completely ruled out.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:37 PM, Philipp Hörist  
wrote:

You get the password in plain at the point when the user creates the
account. Then you save it in 1 and 256.


In this case what prevents an operator to store plain password
as well? And we force him to do so, when he also runs
STUN/TURN/SIP service with the same credentials (the
problem which is totally ignored).

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited  wrote:

Depending on the TLS
library you use, it may also not give you the TLS first message unless
you're not doing renegotiation, in which case you're also safe.


There is another problem with TLS offload, because to my
knowledge "proxy protocol" (supported by haproxy and others)
doesn't support forwarding of TLS handshake messages
(or tls-unique along) to the backend (i.e. XMPP server).

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited  wrote:

To my knowledge, we don't have a good solution for this.


Okay. In this situation the only solution for me is not
implementing anything except SHA1 to avoid interop problems.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Evgeny]

On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus  
wrote:

Then you can't authenticate unless the server also stores the
authentication data for SCRAM-SHA1. I guess that is your point. What 
is
wrong with the server storing the required data to authenticate 
clients
with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation 
overhead

argument)? Maybe I am missing something?


I am not sure what you mean. I can only do that on the server
if I get plain password from the client which is something SCRAM
was designed to prevent if I understand it correctly.
Also, the problem still remains with upgrading existing
SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there
is possibility to create interop problem again, unless a client
1) supports all previous SHA versions
2) doesn't treat previous SHA versions as a downgrade attack

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] SCRAM interoperability

[Evgeny]

Hi there.

Can someone please clarify how to maintain ineroperablity of
SCRAM-SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g.
when some clients support SCRAM-SHA1 only, but the password
was created in SCRAM-SHA256 format. I know it's still
possible to authenticate via PLAIN, however:

1) Using PLAIN creates a potential DoS for the server
due to expensive HMAC computational rounds.
2) Some admins prefer to disable PLAIN completely.
3) A client may see PLAIN as a downgrade attack. This
can happen when the password was changed from another client
with an incompatible SCRAM version.

Another problem is with "-PLUS" formats. RFC 7677 states:

> After publication of [RFC5802], it was discovered that Transport
> Layer Security (TLS) [RFC5246] does not have the expected properties
> for the "tls-unique" channel binding to be secure [RFC7627]

Does that mean that "-PLUS" doesn't provide additional security
and is now useless?

And yet another problem is that SCRAM is
unusable with third-party services such as STUN/TURN or SIP
which support only DIGEST HTTP-like authentication and
thus preventing from sharing the same credentials between
the services.

I'd like to see XSF taking a clear position on this
as well as creating some recommendation for the implementors
because the disambiguation creates interoperability problems.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0292: vCard4 - advance?

[Evgeny]

On Sat, Jan 19, 2019 at 11:44 PM, Kim Alvefur  wrote:

I would like to see XEP-0292: vCard4 Over XMPP advanced. Since
popularity and deployment of XEP-0084 appears to be on the rise, much
thanks to XEP-0398, now seems like a good time to dust it off and 
finish

it.


Given that "modern" clients don't even render vCards
I'm not terribly motivated to implement it in ejabberd.
Even if vcard4 is stored in PEP only, the convertion
between old and new ones should be implemented,
or otherwise we will get into the same situation as
with bookmarks and avatars.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Evgeny]

On Fri, Jan 18, 2019 at 12:19 PM, Dave Cridland  
wrote:
is that those same people will expect to be able to have their 
specifications rubber-stamped through the process.


I fail to see how this is even possible within the XSF process.
If the spec is bad it will get -1 from the Council.
But I, however, agree that we should not require an implementation
during an experimental stage.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Evgeny]

On Thu, Jan 17, 2019 at 8:41 PM, Ненахов Андрей 
 wrote:

Yes, so far this process has led XMPP to a great success, with jabber
being used as a primary communication protocol by a significant
portion of internet users.


You will be now told that this is irrelevant and basically
everything XSF does is irrelevant to XMPP success :)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Evgeny]

On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  
wrote:
we do not require it until Final - not even Draft has an absolute 
requirement.


I thought transitioning to Draft requires Call For Implementors,
but whatever. Again this raises a question about how sane all
those XEP statuses nowadays. I know this is copied from IETF
workflow, but they have the same problems: a large number of RFCs
without implementations or with abandoned partial implementations.

But since the XSF standards development is severely understaffed
I think raising these questions makes even less sense (actually
this is true for almost any XSF workflow nowadays because of this).

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Order-By

[Evgeny]

On Sun, Jan 13, 2019 at 2:40 PM, Goffi  wrote:
Future XEPs may extend this, but in case where it's too complicated, 
implementation has always the choice to not implement it, or to have 
different features with different backends.


I really don't see how this will work in practice.
1) a client issues a request with "direction"/whatever attribute
2) a server responds with "not-implemented" or some such
3) a client gets stuck? or should it re-send a modified request?

Second problem is that competition in servers is quite high
and if customers/users want the feature then I have to implement it 
somehow.

That has happened in the past already.

Third problem is assuming SQL-only backend to support the
feature is the wrong approach, in my opinion.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Order-By

[Evgeny]

On Sun, Jan 13, 2019 at 2:16 PM, Goffi  wrote:
For Pubsub services based on SQL or NoSQL databases, it should not be 
too hard to implement as ordering is most of time a part of API.


Note however, that some NoSQL databases only support a single index
in the query, DynamoDB is such an example. You can apply post-filtering
of course (kinda map-reduce, where filtering is "reduce"), but it may
become inefficient depending on the query subset.

That's just a thing to consider if you want to go too broad in
your specification.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Order-By

[Evgeny]

On Sun, Jan 13, 2019 at 2:16 PM, Goffi  wrote:

a XEP for XPATH like syntax


And the server will process this XPATH query?
Not sure if you're serious...

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Order-By

[Evgeny]

On Mon, Jan 7, 2019 at 8:28 PM, Goffi  wrote:
Are you talking about the fact that "date of modification" (as 
defined in the protoXEP) could be out of sync between clusters?


No, from the discussion I thought you want to have something like 
incremental

unique "order" attribute in the node.
And sorting by timestamps is fine by me.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Order-By

[Evgeny]

On Mon, Jan 7, 2019 at 10:44 AM, Goffi  wrote:
Is there any implementation in the wild which would have issue with 
node order?


Sure, any clustered database will have issues with
such naive approach: after partitioning during merge
you'll end up with duplicated orders, like 2 items
with order=4.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Histroy tranfer idea

[Evgeny]

On Sat, Jan 5, 2019 at 8:02 PM, Ненахов Андрей 
 wrote:

That was a joke. Of course, decent developers these days should use
json for tasks like these.


LMAO

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Histroy tranfer idea

[Evgeny]

On Sat, Jan 5, 2019 at 6:35 PM, j.r  wrote:

Why do you think this? I think that wouldn't that much complicated...


Because replication in distributed systems is an absurdly
complex topic by itself and this complexity will inevitably
lead to implementation bugs which is even harder to debug
than bugs in multi-threaded system.

It's somewhat possible to design this from scratch in relatively
straightforward way, but with all that XMPP baggage I'm very skeptical.

Going a bit offtopic: we still have a lot of problems with message
delivery in XMPP, for example, we have no protection against server
failures during message delivery or we don't have reliable delivery
in presence of s2s failures. Yet, you want to add another source
of message delivery failures.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Histroy tranfer idea

[Evgeny]

On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland  wrote:
Out of curiosity, do we know if the cryptographic properties involved 
in sending a known set of plaintext about like that stack up?


I wonder how everyone is fixated on crypto part while the hardest
part is messages replication itself: in the described scenario we
introduce several replicas of messages - client devices (which can
be many) and a server. This quickly rises several questions related
to a replication in distributed systems:
1) how to perform deduplication
also, if MAM is disabled on the server:
2) how to maintain message casuality (among client devices)
3) how to maintain replica merges after partitions (between client 
devices)


While I like the idea of messages replication between user devices,
I think the implementation will be too complex for a regular XMPP 
client developer

even if we write down all this in a XEP.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

[Evgeny]

Just for the record,
this is not implemented in ejabberd, because this won't work
in clustered environment and locally you need some atomic operations
(if you support SMP) which sucks. At least from what I remember.
Not worth the effort, IMO.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

[Evgeny]

On Fri, Nov 30, 2018 at 10:10 AM, Ненахов Андрей 
 wrote:

in our group chat protocol we did the following


So we now have muc light, muc sub, xabber muc, original muc and mix.
Who is next?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-11-14

[Evgeny]

On Tue, Nov 20, 2018 at 6:43 PM, Florian Schmaus  
wrote:

On 20.11.18 15:54, Georg Lukas wrote:

 * Tedd Sterr  [2018-11-15 20:41]:
 8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 
'disco#info' responses - https://github.com/xsf/xeps/pull/716


 -1, but we should add the Note about examples not being normative.


The primary purpose of the (unwritten) rule that examples are 
considered

non-normative is that broken examples cannot become or seen as correct
behaviour as of the specification. Your suggestion would add another 
use
case to the rule and explicitly encourage broken examples. I fail to 
see

why we would want to do that.



I think examples should not omit required elements, such as 'id' 
attribute of
iq stanzas, 'disco#info' feature in 'disco#info' responses and so on. 
If such

an element is omitted, it must be replaced with `...` or something.



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0398: Avatar Conversion, resend presence

[Evgeny Khramtsov]

Sun, 2 Sep 2018 10:22:40 +0200
Emmanuel Gil Peyrot  wrote:

> This is wrong, XEP-0045 notes that RFC6121 mandates that a server
> would broadcast an unavailable presence to all previous directed
> presence targets, this means the server MUST track them

Well now this is wrong :) The server only tracks presence's recipient
JID, it doesn't store full presence stanza, because this is not cheap.
This is enough to send presence-unavailable, but it's not enough for
stanza resending (for example, caps information will be lost).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] field report on authentication methods

[Evgeny Khramtsov]

Thu, 9 Aug 2018 10:54:17 -0600
Peter Saint-Andre  wrote:

> hereas 4% for XEP-0078 is a fairly large percentage. I'd want to
> do further investigation regarding client versions before shutting off
> 4% of our users...

I'm 99% confident that those 4% are in fact bots using abandonware
(most likely some monitoring tools). Strictly speaking you don't cut off
users, but only automated software.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-06-20

[Evgeny Khramtsov]

Wed, 27 Jun 2018 09:34:02 +0200
Goffi  wrote:

> It would be even better to be able to list existing files and delete
> them on request, but this can be done in a separated XEP.

As someone already mentions here (or in another list/chat), a user may
not want a server to keep tracking their files, especially when e2ee is
used and the file is encrypted. So, yes, listing expiration date is
great, but also a server should notify a client whether it's possible
to upload files anonymously (without tracking) or not, and a client
should set this flag when requesting a slot.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Evgeny Khramtsov]

Thu, 10 May 2018 12:39:54 +0100
Dave Cridland  wrote:

> XEP-0060 takes a message protocol and builds a pubsub service on top.

I don't want to run into terminology debates, but XMPP strictly
speaking is not a "message protocol", but a protocol for XML routing.

> You're suggesting that MIX should build a message service on top of
> this?

Yes. MIX should build a message service on top of XML packets.

> The problem, in my eyes, is that we have existing, well-defined,
> handling for the concepts of "messages" and "presence", and I would
> hate to have to deal with these entirely differently for group chat
> compared to for 1:1 chat.

There is probably no need to say for the 1000 time that the conception
of "presence" is outdated. I also doubt messages by itself is a good
concept. Yes, they are easy to understand for sure, but seems like in
modern IM we are talking about replicas exchange between endpoints.
The simple concept of a message carrying human readable text 1:1 is
somewhat outdated too. Sorry for the "moot statements", but you started
this discussion in the first place. Frankly, I would rather discuss
technical aspects instead of this philosophic bullshit.

> There are always going to be differences, of course (short of forcing
> every 1:1 conversation into a  2-person groupchat, which has its own
> unique problems), but it makes sense to me to minimize these, and
> reuse existing handling wherever possible.

Well, I actually suggest to reuse existing specification and, what's
more important, existing code. Pubsub is something we have more or less
implemented, and can reuse it, despite it doesn't fit ideology of some
people. Your vision of Pubsub as a "building block" is wrong in my
opinion, because this doesn't help me at all, I need to reimplement
*all* pubsub code to handle MIX, because now Pubsub is not a protocol
between a client and a disc storage, but rather some abstract stuff
used by ad-hoc services which translate Pubsub requests in their
internal state.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Evgeny Khramtsov]

Thu, 10 May 2018 12:14:12 +0100
"Steve Kille"  wrote:

> I'm not sure that I understand your question here.   MIX does use a
> PubSub node for message distribution.

Great. So this use case should be described in the core: i.e.
pubsub without ad-hoc services. Other stuff (like presence, anonymous
messaging and so on) should go into separate documents (which will
require some additional services as I understand).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Evgeny Khramtsov]

Thu, 10 May 2018 11:46:10 +0100
"Steve Kille"  wrote:

> Sometimes the nature of problems does not lend itself to short
> specification.The basic PubSub and MIX concepts are simple.
> However, there is a lot of devil in a lot of details that needs to be
> addressed. Ending large is not a goal, but is often a consequence
> of addressing real world problems.

Philosophic discussions aside, can you please tell what we're missing
from the use case mentioned by Jonas:

> essentially Joining, Leaving and Messaging, without any presence things

Why we cannot use a pubsub node for this? The main argument I
recall is that you cannot identify a sender, but this is not true,
because we have a 'publisher' attribute. Another argument is that we
cannot make it anonymous, but I think anonymous publishing should be a
separate extension in the first place. We have some ability to set
metadata, we have simple ACL configuration. So what details do we need
to address?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Evgeny Khramtsov]

Thu, 10 May 2018 11:21:43 +0200
Daniel Gultsch  wrote:

> What worries me about MIX is that it looks like such a big spec that
> no body is going to implement fully that years from now we are still
> going to find 'bugs' in the XEP. Like we recently found 'bugs' (under
> specified things) in PubSub and that XEP is 15+ years old.

I agree with this (as I said many times). And I of course disagree with
the XEP author: comparing MIX with other poorly implemented monster
specs assuming that this is "normal" is beyond me.

I'm for sure vetoing MIX implementation in ejabberd in the form it's
presented currently. As I said: we just have to use pubsub and improve
pubsub spec if we miss some really basic functionality. And I agree
with Holger: if we cannot reuse pubsub for such simple functionality as
group messaging then why we need pubsub at all?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Evgeny Khramtsov]

Mon, 30 Apr 2018 13:20:38 +0200
Jonas Wielicki  wrote:

> I agree with your stance about deletion. Which is why I made it a
> separate PR.
> 
> What do you think about the independent extension to the text I
> proposed in https://github.com/xsf/xeps/pull/625 ?

While I'm fine with having a separate extension, I'm against the PR
itself. I think the behaviour is up to a local policy. We shouldn't make
default recommendations based on some local laws (GDPR). Because if we
do that, we can easily add "NOT" to all "SHOULD"s, and in this case we
will describe the local law of Russia (where it is required to keep all
users data for at least 6 months). I would really advise XSF to avoid
making political statements. Not to mention that the text brings
nothing to the document and only increases its size: it doesn't
describe any protocol, it doesn't describe security considerations, it
doesn't describe UX, so what does it do? Can we replace the text with
"People SHOULD live in peace?" Because the meaning of the statement
doesn't change a lot and a reader can easily ignore it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0357 (push) needs options

[Evgeny Khramtsov]

Fri, 13 Apr 2018 13:15:03 +0500
Ненахов Андрей  wrote:

> The only correct way to send pushes is when user should recieve some
> new content (messages).

What about Jingle calls? Do we support them in the XEP? How a server
knows what to send?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-04-11

[Evgeny Khramtsov]

Thu, 12 Apr 2018 23:47:09 +
Tedd Sterr  wrote:

> Isn't this the point of the CFE - to find out?
> There is always the *possibility* that somebody somewhere could
> possibly maybe have implemented a given feature, but if nobody knows
> about it, do we just assume it does anyway? In which case, we can
> always assume there are enough implementations because there *might*
> be.

That's why back in the days I suggested to keep track of
XEP implementations. However, I was told the information there would be
inaccurate. But I fail to see how polling a few users in rare meetings
is going to be more accurate. Another objection is that XSF needs a lot
of efforts to keep this table up to date. And this might be true, of
course.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: IM Routing-NG

[Evgeny Khramtsov]

Wed, 28 Mar 2018 23:12:03 +0200
Manuel Rubio  wrote:

> I was reading XEP-0344 (Impact of TLS and DNSSEC on Dialback). I 
> understand that's for security connection between two XMPP servers 
> (S2S).

I meant XEP-0334 (Message Processing Hints) of course, sorry.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: IM Routing-NG

[Evgeny Khramtsov]

Wed, 28 Mar 2018 17:18:36 -
Jonas Wielicki (XSF Editor)  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: IM Routing-NG
> Abstract:
> This specification provides a new set of routing rules for modern
> instant messaging.

Not sure why XEP-0344 can't be used for this. We just need to set
 in Example 6 and for other cases we need to introduce new
 element and a server's disco feature (I would rather use stream
feature, but one can argue it should be negotiated blah-blah-blah).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Review of XEP-0369: Mediated Information Exchange (MIX) v0.9.5

[Evgeny Khramtsov]

Fri, 23 Mar 2018 20:57:41 +
Kevin Smith  wrote:

> Thanks for the review, comments follow (I’ve elided trivial points).
> 
> On 20 Mar 2018, at 16:34, Florian Schmaus  wrote:
> > As of now MIX is bloated and got way out of hand.  
> 
> I’m not sure to what extent this is true, but I’m going to go through
> and see what can be simplified.

I think the core of the XEP should not rely on ad-hoc services: the
whole protocol should re-use existing pubsub spec. For relaying
messages this would be enough. Other stuff like presence management,
jid proxy, access rules and other nerdy features should go into an
ad-hoc service and should be described in a separate document.

> MIX is a very simple core concept

XEP-0136 had also a very simple concept.

> and I’m not entirely sure how we’ve got to the current situation
> where it’s viewed as complex

The XEP is 91 pages long. Even reading it will take a day.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Evgeny Khramtsov]

Sun, 18 Mar 2018 21:17:16 +0100
Philipp Hörist  wrote:

> If you want to work on MUC, there are a hundred threads about the
> upcoming MIX standard.

I hope this will never become an adopted standard.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Evgeny Khramtsov]

Sun, 18 Mar 2018 18:56:48 +0100
Jonas Wielicki  wrote:

> Two or more clients updating different bookmarks at the same time (or
> maybe at different times, but one had a network outage inbetween and
> can only actually perform the update at a later time). Currently, it
> requires a nasty loop [1] until convergence to make that work.

You need this loop too if you want to modify the same item (i.e. the
bookmark of the same conference).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Evgeny Khramtsov]

Fri, 16 Mar 2018 20:11:19 +
Tedd Sterr  wrote:

> > This is true, however mostly these are quite coarse-grained.
> > Extensions with lots of optional  
> 
> > parts inside - I'm thinking about XEP-0060 for example - tend to
> > end up with various interop issues.  
> 
> I don't disagree with that, and I'm not suggesting 0394 turns into a
> mass of optional parts.

So you only want to add a single part? But then comes another person
with another feature request, then yet another one and eventually we
have a mess of optional parts :)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Evgeny Khramtsov]

Thu, 15 Mar 2018 11:31:37 +0100
"W. Martin Borgert"  wrote:

> Many people know Markdown syntax nowadays, there are parsers for
> it in many different programming languages, and we already know
> how ugly and illogical it is. Just needs a new XEP :~)

>From what I understand you can use markdown with that another XEP: e.g.
you can use `foobar` in the text and the client software will add
corresponding markup elements from that another XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Evgeny Khramtsov]

Thu, 08 Mar 2018 08:51:26 +0100
Jonas Wielicki  wrote:

> How many XMPP clients have you seen which were owned by Billion
> Laughs (which uses entities which are explicitly forbidden in RFC6120
> and trivial to turn off in all XML parsers I’ve seen so far) compared
> to the amount of XMPP clients Sam has found which were vulnerable to
> XHTML-IM XSS attacks? I think the comparison might not hold up, but
> I’m open for data. (Likewise for any other XML vulnerability.)

I don't know, I didn't count and not going to count them for you. Kids
these days might not remember, but Billion Laughs was pretty serious
vulnerability despite being well known with several implementations
affected. So new XMPP implementations might be vulnerable just easily.

> Also, XML vulnerabilities are both well-known and easy to test
> against (in the sense: it is easy to write an automated test which
> ensures that code is not vulnerable).

And where are those tests?

> I don’t think that’s so trivial with XSS attacks. During the
> XHTML-IM debate I learnt that even CSS can be an XSS vector (in some
> really broken implementations

Sure, and were there debates of possible XML security holes? So the
comparison is not quite fair. Not to mention that it's a logical
fallacy to speculate about possible vulnerabilities: one can say
everything might have security issues.

> In contrast to XML, XHTML-IM is a custom thing which needs to be re-
> implemented in ~every client. Well-known XML libraries exist for most 
> languages (even if they only FFI to libxml2 or libexpat).

Well-known XML libraries didn't protect from Billion Laughs attack. Not
sure what this argument is for.

TL;DR: I conclude that the only argument is that XML is a bit more
secure (with possibly less possible holes, lol). So, as I thought, this
is purely a matter of personal choice and not a technical decision,
that's why we debated about it so much.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Evgeny Khramtsov]

Wed, 07 Mar 2018 21:33:13 +0300
Kozlov Konstantin  wrote:

> So, the only reason to obsolete the XEP is not the XEP itself, but
> bad implementations?

Yes. This is kinda religion among some Council members that if a
technology can be misused then it should be deprecated. Their religion
is, however, quite picky: there is a well-known list of security
problems in XML (including the famous billion laughs attack), but they
don't consider to get rid of XML.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Agenda 2014-02-28

[Evgeny Khramtsov]

Wed, 28 Feb 2018 15:05:32 +
Dave Cridland  wrote:

> 2014-02-28

Time machine?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

[Evgeny Khramtsov]

Sat, 24 Feb 2018 11:24:39 -0500
Travis Burtrum  wrote:

> Unfortunately you also can't reasonably expect P2P to work today in
> most cases because everyone is behind a NAT including most mobile
> phone networks. So https is still your best bet, and since most
> servers support http upload it's already done for you.

This problem is solved already by TURN servers.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Thu, 15 Feb 2018 08:18:24 +0100
Daniel Gultsch  wrote:

> I want to put the current MAM preferences into the a disco features
> form on the account.

Ah, ok then.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Wed, 14 Feb 2018 10:01:31 -0600
Sam Whited  wrote:

> I'm sure we'll discuss this is the council meeting, but to my
> knowledge this is the only part of the spec that anything implements
> now (please correct me if there is significant adoption of the other
> parts of the spec).

Well, as Daniel noted, blindly purging all offline nodes is risky in a
general case because you don't know if MAM is enabled in user's
preferences. As a work-around you can first request the number of
messages (before sending an initial presence), this, according to the
spec, will automatically disable offline messages flood. In a later
stage you can check if MAM is enabled and if it is, you purge, if it's
not, you retrieve offline messages via any mechanism described in
XEP-0013. Thus, other parts of specs can also be utilized. I know, this
is ugly, but at least doable. For sure, new mechanism is needed in this
situation (such as MAM interface to offline storage, dunno).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Tue, 13 Feb 2018 17:04:36 +
Dave Cridland  wrote:

> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
> 
> https://xmpp.org/extensions/xep-0013.html

Just my 3 cents: this XEP is, from what I know, the only way to disable
offline messages on a client, so we need a similar mechanism if the XEP
is going to be deprecated.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Entity Capabilities 2.0

[Evgeny Khramtsov]

Mon, 12 Feb 2018 09:12:02 +0100
Jonas Wielicki  wrote:

> Could you please be specific which cache you’d like to see properly 
> invalidated? Do you mean the (hash -> disco#info) cache or the
> (entity JID -> hash / disco#info) cache?

A server can change configuration in runtime at any time, potentially
changing its disco#info. How to notify local clients about that? How to
notify clients from remote servers? How to notify connected servers after all?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Entity Capabilities 2.0

[Evgeny Khramtsov]

Mon, 12 Feb 2018 00:41:54 +0100
Christian Schudt  wrote:

> - I am also missing a cache which maps entities to capabilities, i.e.
> JIDs to disco#info objects. This is the whole point of the XEP (to be
> able to know an entity’s abilities without service discovery). This
> cache should be probably be non-persistent. The "Capability Hash
> Cache“ (hash -> disco#info) is actually only the
> intermediate/auxiliary cache.

I think the XEP doesn't solve the main problem of cache invalidation
and that's why I think it's pointless and I'm not going to implement it
until the invalidating rules are described. And for those who think
cache polution is a problem can request/store features per JID: there
is absolutely no need to introduce yet another incompatibility just for
a very tiny problem which can be solved in the other way.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 14:21:49 +0100
Daniel Gultsch <dan...@gultsch.de> wrote:

> 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov <xramt...@gmail.com>:
> > Thu, 8 Feb 2018 13:17:14 +0100
> > Daniel Gultsch <dan...@gultsch.de> wrote:
> >  
> >> at least for MUC I would prefer vCard + hash in presence from the
> >> bare muc jid. (as discussed in our 34C3 meeting and/or various
> >> discussions we had prior to this)  
> >
> > What was the conclusion? (If any)  
> 
> 
> The question I had for the room was basically if any client would
> break on receiving presence from the bare jid and everyone (in the
> room) agreed that *their* client wouldn't break.
> 
> On whether or not this is a good idea; I can't remember anyone voice
> strong objections.

Good. Then I will implement this in ejabberd.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 13:17:14 +0100
Daniel Gultsch  wrote:

> I don't have an opinion on pubsub.

I guess that's not a problem for PubSub service to send
notifications? :) A dedicated and well-known node should be enough for
this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 13:17:14 +0100
Daniel Gultsch  wrote:

> at least for MUC I would prefer vCard + hash in presence from the bare
> muc jid. (as discussed in our 34C3 meeting and/or various discussions
> we had prior to this)

What was the conclusion? (If any)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___