Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>
> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> > (And please, folks, unless you can think of something I can't, a
> > randomish string prefix and a counter is fine).
>
> The dangers of using counters in stanza IDs and leaking information :)

Yes, quite. I meant to argue against generating UUIDs and otherwise using a
lot of entropy, and got carried away - but a random key and hmaccing a
counter should be okay.

Point being, if the stanza id attribute is causing us a problem, that can
be fixed in compatible ways.

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

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> (And please, folks, unless you can think of something I can't, a
> randomish string prefix and a counter is fine).

The dangers of using counters in stanza IDs and leaking information :)

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

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 28 September 2016 at 17:38, Kevin Smith  wrote:
> Sadly not, 6121 says
>  " It is up to the originating entity whether the value of the 'id'
>attribute is unique only within its current stream or unique
>globally.”

Equally, absolutely nothing stops a client issuing globally-unique (or
at least, bare-jid-unique) stanza identifiers on all stanzas.

I'd be up for saying something along the lines of:

"Where the previous message is from a different full jid, the receiver
MAY choose to treat it as a new message, and MUST do so if the bare
jid is not known to be a normal user account. Clients wishing to
correct messages from other client instances of the same user (and
thus using different full jids) MUST use globally unique stanza
identifiers, and SHOULD ensure the message they are correcting is from
a client which advertises this feature."

Then somewhere define a feature for globally unique stanza ids -
possibly in a new XEP.

(And please, folks, unless you can think of something I can't, a
randomish string prefix and a counter is fine).

This would remain compatible with the (draft) spec.

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

Re: [Standards] XEP-0359 Client vs. non-client IDs

[Kevin Smith]

On 29 Sep 2016, at 19:08, Florian Schmaus  wrote:
> 
> On 29.09.2016 19:22, Guus der Kinderen wrote:
>> Hi,
>> 
>> What's the purpose of the distinction between "Unique Stanza IDs" and
>> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id
>> elements (each with a unique 'by' attribute value), and not worry about
>> what entity is serving in a client-capacity?
> 
> It was designed that way to avoid leaking the client's XMPP address in
> cases like MUC. Notice that  has a 'by' attribute whereas
>  has not. I should add that rationale to the XEP.

That makes sense, but why not just say something like “the stanza-id without a 
by is the originating entity”. Else sometimes the orginating entity stamps with 
a client-id (when it’s a client) or doesn’t (when it’s a server), or you have 
servers stamping with client-id, or whatever.

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

Re: [Standards] XEP-0359 Client vs. non-client IDs

[Florian Schmaus]

On 29.09.2016 19:22, Guus der Kinderen wrote:
> Hi,
> 
> What's the purpose of the distinction between "Unique Stanza IDs" and
> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id
> elements (each with a unique 'by' attribute value), and not worry about
> what entity is serving in a client-capacity?

It was designed that way to avoid leaking the client's XMPP address in
cases like MUC. Notice that  has a 'by' attribute whereas
 has not. I should add that rationale to the XEP.

- Florian




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

Re: [Standards] XEP-0359 Client vs. non-client IDs

[Kevin Smith]

On 29 Sep 2016, at 18:22, Guus der Kinderen  wrote:
> What's the purpose of the distinction between "Unique Stanza IDs" and "Client 
> generated stanza IDs"? Why not add a unbounded list of stanza-id elements 
> (each with a unique 'by' attribute value), and not worry about what entity is 
> serving in a client-capacity?

+1

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

[Standards] XEP-0359 Client vs. non-client IDs

[Guus der Kinderen]

Hi,

What's the purpose of the distinction between "Unique Stanza IDs" and
"Client generated stanza IDs"? Why not add a unbounded list of stanza-id
elements (each with a unique 'by' attribute value), and not worry about
what entity is serving in a client-capacity?

Regards,

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

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Florian Schmaus]

On 29.09.2016 12:55, Florian Schmaus wrote:
> On 27.09.2016 11:06, Tobias M wrote:
>>> On 27 Sep 2016, at 00:33, Kevin Smith >> > wrote:
 What do you think? Do you have further comments on this issue?
>>>
>>> I think there’s also a concern that different resources may use the
>>> same IDs. Perhaps we should be moving away from using stanza IDs for
>>> this, and move towards something like 359 (although 359 has the
>>> client-id, stanza-id oddity which we should probably fix at some point
>>> and just use multiple stanza-id stamps with the relevant ‘by’ instead).
>>
>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could
>> provide a solution if we can’t rely on unique and stable stanza IDs.
>> It’s not discussed in XEP-0359, but I guess it’s the reason for its
>> existence, that stanza IDs may only be stable/unique regarding one XMPP
>> stream and might change in a multi-hop routing like C-to-S -> S-to-S ->
>> S-to-C or C-to-S -> MUC -> S-to-C.
> 
> Correct

Although I believe that non-xep359 stanza IDs should be stable in the
"c2s → s2s → s2c" case you gave, as error stanzas and IQ responses could
not be matched any more otherwise. But your MUC example is correct. I
remember that people have found that xep45 allows MUC services to change
the stanza id when the stanza is reflected by the service. Which causes
some trouble for client developers. Another potential use case for
xep359 are, of course, archiving services like MAM.

- Florian




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

Re: [Standards] OpenPGP IM: all stanza types supported?

[Fabian Beutel]

Hey Florian,

thanks for your feedback.

> Yes and No. XEP-0373 defines an extension element called 
> which carries OpenPGP encrypted and/or signed data. It does not talk
> about (full or not full) stanza encryption per se, although full stanza
> OpenPGP encryption using the  element would be possible..
> 
> XEP-0374 is an application profile for XEP-0373. It explains and shows
> examples of extension elements to be wrapped into an  element
> like message bodies or XHTML-IM.

That's how I understood it. I guess my suggestion would be to move
the focus of XEP-0374 from describing what elements an  element
can contain to describing what can contain an  element, which
(at least to me) seems to make more sense.

> That 'SHOULD' was put there deliberately. We don't think that it would
> be a good idea to require implementations to support every possible
> extension element wrapped into a . However I could imagine
> that we create a small minimal required set of extension elements which
> have to be supported once a feature like 'urn:xmpp:openpgp:im:0' is
> announced. Possible this set would just consist of '.

I guess currently every client implementing XEP-0373 automatically
satisfies all requirements from XEP-0374, as there are basically none.
It's formally not required to be able to handle *any* encrypted element.
Even the three examples in the XEP (,  and ) are
never strictly required to be supported by a client. All it says is that
"for example, direct child elements found in  in the context
of IM could be" those three.
So if I talk to a client advertising 'urn:xmpp:openpgp:im:0', that
doesn't give me any knowledge about what elements I can encrypt!

So you suggest to define a set of elements which have to be encryptable.
However, I can't think of any reason why requireing every possible
extension element to be encryptable is a bad idea. Can you give some
examples where this may be bad?
I mean from an implementation point of view it is probably the easiest
to just implement encryption transparently. Just go through the stanza
and replace every , done.
And say, for example, we only require  elements to be supported.
Any implementation receiving a message would have to decrypt the payload
anyways before it knows that it contains a  element, so it just
seems just intuitive to just use the content anyway, no matter what it is.
I think this is another reason on why we should make the distinction
between *what can contain* encrypted elements (e.g. only ), not
what elements are required to be handled if encrypted.

> [...] And I see what you try with your 'Stanza support'
> section, but XEP-0374 is just not the right place to specify it, because
> it's really just about exchanging IM messages. If you want OpenPGP
> secured Presence and IQ stanzas, then those should be defined in an
> extra XEP which reuses the building blocks for XEP-0373. That's the idea
> behind the XEP-373/374 split. 373 provided the fundamental primitives
> which can be used in other XEPs to specify OpenPGP application profiles.

I understand that there may be different requirements in a non-IM scenario,
but IQs are also explicitly part of the Xmpp-IM-Specification (RFC 6121)
and I think it makes sense to include them in such an application profile.

> We already had some discussion about OpenPGP secured Presence/IQ in the
> past. But OpenPGP secured Presence is at least controversial, because it
> will possible (depending on how you design it) leave your key unlocked
> and the benefits are minimal.

Okay, for Presence I also fail to come up with a strong argument for
supporting it. However, in the case of IQs it could have great benefits,
e.g. hiding metadata and IPs and such in the case of Jingle negotiations.

So let me make a new suggestion, then. Maybe we could define several
namespaces (e.g. 'urn:xmpp:openpgp:im:message:0',
'urn:xmpp:openpgp:im:iq:0', 'urn:xmpp:openpgp:im:presence:0') so that
clients could selectively opt-in to what stanzas they are able to receive
encrypted? I think this could all be handled in one XEP and defining three
separate XEPs would probably be very redundant...

> 
> > [1] The situation in example 3 in XEP-0374, where the containing stanza
> > already has a  element ("This message is encrypted using
> > OpenPGP.") could be handled by requiring that in case of a name
> > conflict (an element already exists) the encrypted element always takes
> > precedence over the unencrypted one.
> 
> I would have bet we already added such a rule. But if not, it should be
> considered.

Okay, I haven't found it but of course I might have missed it. :)

Thanks again for your feedback and best regards,
Fabian
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OpenPGP IM: all stanza types supported?

[Florian Schmaus]

On 29.09.2016 00:00, Fabian Beutel wrote:
> First, did I interpret the OpenPGP-XEP-0373/374 correctly that any
> stanza can be encrypted and not only messages?

Yes and No. XEP-0373 defines an extension element called 
which carries OpenPGP encrypted and/or signed data. It does not talk
about (full or not full) stanza encryption per se, although full stanza
OpenPGP encryption using the  element would be possible..

> If so, I think it might be good to explicitly state that in XEP-0374.

XEP-0374 is an application profile for XEP-0373. It explains and shows
examples of extension elements to be wrapped into an  element
like message bodies or XHTML-IM.

> Also, I would suggest to strictly require implementations to
> transparently handle the content of the  element.
> "[...] SHOULD be processed similar as if they had been direct extension
> elements of the stanza" may be a to vague - here I would suggest to use
> MUST instead. [1]
> 
> That way, when I'm talking to a client that supports XEP-0374 I can be
> sure that it understands any encrypted stanza I send and for example
> jingle negotiations could happen encrypted.

That 'SHOULD' was put there deliberately. We don't think that it would
be a good idea to require implementations to support every possible
extension element wrapped into a . However I could imagine
that we create a small minimal required set of extension elements which
have to be supported once a feature like 'urn:xmpp:openpgp:im:0' is
announced. Possible this set would just consist of '.

> I created a pull request for these suggestions and would be happy if the
> authors would take a look at it! [2]

I'll comment on your changes here. As I said above, the 'SHOULD' was
chosen for a reason. And I see what you try with your 'Stanza support'
section, but XEP-0374 is just not the right place to specify it, because
it's really just about exchanging IM messages. If you want OpenPGP
secured Presence and IQ stanzas, then those should be defined in an
extra XEP which reuses the building blocks for XEP-0373. That's the idea
behind the XEP-373/374 split. 373 provided the fundamental primitives
which can be used in other XEPs to specify OpenPGP application profiles.

We already had some discussion about OpenPGP secured Presence/IQ in the
past. But OpenPGP secured Presence is at least controversial, because it
will possible (depending on how you design it) leave your key unlocked
and the benefits are minimal.

> [1] The situation in example 3 in XEP-0374, where the containing stanza
> already has a  element ("This message is encrypted using
> OpenPGP.") could be handled by requiring that in case of a name
> conflict (an element already exists) the encrypted element always takes
> precedence over the unencrypted one.

I would have bet we already added such a rule. But if not, it should be
considered.

Thanks for you feedback.

- Florian




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

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

[Dave Cridland]

On 29 September 2016 at 09:41, Kevin Smith  wrote:
> On 27 Sep 2016, at 17:18, Sam Whited  wrote:
>>
>> On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille  wrote:
>>> A simple approach to address this more complex scenario is a two-step
>>> approach where the inviter starts by sending a message to the channel to
>>> grant the invitee rights to join the channel and then sends a simple invite
>>> to the invitee.
>>>
>>> This seems much simpler than the current descriptions of passing tokens
>>> around, and is to my mind a preferable approach.  Is there a requirement
>>> that I am missing, which needs the token passing approach?
>>
>> I personally prefer a simple token based approach for two reasons:
>>
>>  * We may not know the invitee's JID to request that the server allow
>> it (eg. if we're sending the invite out of band via an email)
>>  * We may not want to maintain a list of people who have been invited
>> (eg. if we wanted to have some form of stateless authentication
>> gateway that users connect too to determine if they're allowed into
>> the MIX)
>>
>> The first example is obviously solved by use of a token, and the
>> second example can be solved by sending an HMAC as the token, then
>> instead of storing it, we just validate any tokens
>> sent back to the server with the same secret, similar to the way web
>> forms often use HMAC's for CSRF tokens.
>>
>> If we want to have a stateles invite service, but also want to verify
>> all JIDs explicitly, we can always encode the JID in the token (eg.
>> make it a part of the HMAC secret or make the token a signed JSON web
>> token or whatever it's XML counterpart is if such a thing exists).
>>
>>
>> I also think, however, that tokens don't need to be specified in the
>> MIX spec and can be a matter of server policy without clients needing
>> special support by allowing invites to have a
>> server-generated arbitrary payload which MUST be sent back when
>> accepting the invite. This way servers could use tokens (simple
>> tokens, HMACs, signed JWTs, etc.) or simply send an empty payload and
>> validate the JID (or any other scheme they can come up with) and the
>> spec wouldn't have to mention any of them except in passing.
>
> I agree with Sam. It’s easier for servers not to have to keep a state table 
> if they don’t want to, and tokens let them encode it. ISTR Dave also had a 
> use case here where he wanted the MUCs to know that a user was joining 
> because of an invite and so could reject them if the token was wrong, even if 
> the user was allowed to join (because it was possible but inappropriate for 
> them to join in normal circumstances, I think, but I forget the details, I 
> was concentrating on eating curry at the time).
>

My concern was spam invitations, actually, but I suspect there's lots
of useful things one can do if one has an opaque token from the
service.

Really, I think we're after:

1) Inviter sends a token request to MIX channel.
2) MIX channel responds with either a token, or an error (if the
invitee cannot be invited).
3) Inviter sends token onto Invitee. We want this pathway to avoid
privacy list and spamming issues.
4) OPTIONAL: Invitee can check validity of the token with the MIX
channel without causing side-effects. This allows a UI to discard
spammy invites. This might also be an abuse pathway of its own; so
we'll want to keep an eye on this.
5) Invitee can "spend" token within a MIX join. This may or may not
mean that subsequent use of the token fails.

I think this allows Sam's stateless case easily enough, and provides a
set of mitigations against spam invitations as well.

FWIW, I suspect a simple HMAC over the invitee bare jid and the MIX
channel id against a short-term private key held by the MIX channel is
adequate for these tokens for the use-cases discussed so far, but
making it any kind of opaque string should be future-proof. If we
really want, add in a "token-type" attribute and default it to
"opaque". Can't hurt, might provide useful in the future.

As an aside, I think this provides general cover for the passworded
channel use-cases, too - if one considers the password to be simply
another invitation token. But I've not thought this through very far.

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

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

[Kevin Smith]

On 27 Sep 2016, at 17:18, Sam Whited  wrote:
> 
> On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille  wrote:
>> A simple approach to address this more complex scenario is a two-step
>> approach where the inviter starts by sending a message to the channel to
>> grant the invitee rights to join the channel and then sends a simple invite
>> to the invitee.
>> 
>> This seems much simpler than the current descriptions of passing tokens
>> around, and is to my mind a preferable approach.  Is there a requirement
>> that I am missing, which needs the token passing approach?
> 
> I personally prefer a simple token based approach for two reasons:
> 
>  * We may not know the invitee's JID to request that the server allow
> it (eg. if we're sending the invite out of band via an email)
>  * We may not want to maintain a list of people who have been invited
> (eg. if we wanted to have some form of stateless authentication
> gateway that users connect too to determine if they're allowed into
> the MIX)
> 
> The first example is obviously solved by use of a token, and the
> second example can be solved by sending an HMAC as the token, then
> instead of storing it, we just validate any tokens
> sent back to the server with the same secret, similar to the way web
> forms often use HMAC's for CSRF tokens.
> 
> If we want to have a stateles invite service, but also want to verify
> all JIDs explicitly, we can always encode the JID in the token (eg.
> make it a part of the HMAC secret or make the token a signed JSON web
> token or whatever it's XML counterpart is if such a thing exists).
> 
> 
> I also think, however, that tokens don't need to be specified in the
> MIX spec and can be a matter of server policy without clients needing
> special support by allowing invites to have a
> server-generated arbitrary payload which MUST be sent back when
> accepting the invite. This way servers could use tokens (simple
> tokens, HMACs, signed JWTs, etc.) or simply send an empty payload and
> validate the JID (or any other scheme they can come up with) and the
> spec wouldn't have to mention any of them except in passing.

I agree with Sam. It’s easier for servers not to have to keep a state table if 
they don’t want to, and tokens let them encode it. ISTR Dave also had a use 
case here where he wanted the MUCs to know that a user was joining because of 
an invite and so could reject them if the token was wrong, even if the user was 
allowed to join (because it was possible but inappropriate for them to join in 
normal circumstances, I think, but I forget the details, I was concentrating on 
eating curry at the time).

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