XSF Discussion - 2020-01-24

Ge0rG, Genuinely, because people seem to get very confused over the idea.

dwd: I agree with that, and was just wondering about motivation and about what kind of HPKE you want to enroll

Ge0rG, Not entirely sure. HPKE is simple enough that it's relatively easy to build, but has the advantage that we could use the same mechanism based on it for password-based and per-device authentication, since it'll support private keys on both sides, etc. Might be a better/longer-term replacement for SCRAM-SHA-1 than SCRAM-SHA-SOMETHING-ELSE. But I have no clue if there's sufficient eneergy within Kitten to do anything about it.

dwd: do you use HPKE as an acronym for the generic combo of symmetric and asymmetric crypto, or for some specific algo/approach?

Also I'm not quite sure how that fits into the authentication flow

Ge0rG, https://tools.ietf.org/html/draft-irtf-cfrg-hpke-02 and https://github.com/dwd/crypto-examples/blob/master/hpke-demo.py

dwd: this is about encryption of data

Ge0rG, It is. But I think one could build a SASL mechanism around it, sending an encrypted password and establishing a device private key. AAD with channel binding in, too.

In particular, I think you end up with a possibility for a 1-RTT mechanism which has optional per-device keying. But I'm not beyond vague consideration here, I have nothing concrete.

How do those password based TLS key agreement things work?

dwd: I have a vague feeling about doing such a thing over HPKE or actually any asymmetric sign+encrypt thing, but this is designing a new crypto protocol and I don't really feel confident there

PAKE?

Ge0rG, Oh, me neither. I'm confident in putting something together and then asking Richard Barnes, though.

Zash, Deriving a keypair from a password? As I recall, they're nearly all patented in odd ways.

Go north and take it to the mountains?

Zash, Although obviously one could just PBKDF-2 -> 25519 or 448 and be done, these days.

I was under the impression that this existed in TLS already, but wasn't used

Or am I confusing it with pre-shakred static keys?

Zash, Oh, password-based TLS? Yes, that exists.

pre-shaked keys. I want those.

Zash, It's PSK, rather than passwords, but that is again a mere PBKDF-2 away.

Ge0rG, Preshaken keys, never prestirred keys.

Ge0rG: XEP-0257 ?

Zash, IIRC, wetried taking that to th IETF and it died due to lack of interest.

"pre-shakred static keys" "pre-shaked keys" "prestirred keys" <-- I'm having trouble determining which of these, if any, are typo's...

A shakra is a circular vortex of energy on the spinal column.

it only goes downhimm from there.

In MAM, what to do, server sided, with queries that contain unsupported data fields? Ignore them (which adds to confusion)? Throw exceptions (which likely breaks clients)?

I'd fail with an error

You can't break what's already broken :)

and if the client is expecting you to do some filtering that you're not going to do, providing a response is likely to also break it, just in more subtle ways

true

All but the core fields should be discovered before use, the XEP is clear about that

Guus, I agree with MattJ - silently ignoring it is unlikely to do whatever the client was trying to do.

already putting the code in.

Well, arguably, the client is trying to do the wrong thing if it is sending unsupported fields.

But what about including the fields but no values . ..

semantically, the client doesn't want to use those, right?

so, ignore them?

In the general sense, ignoring unknown things has always been to go-to approach. Why would this be different, dwd?

(or MattJ)

Ignoring things isn't always the best approach, even if it is often done

In this case it is demonstrably bad

It's one thing to ignore stuff that you are passing through/routing

But if someone sends you a query with stuff you don't understand, you can't be sure you are properly answering their query

But the client shouldn't be sending that stuff to begin with?

ralphm, We ignore unknown things because the protocols are designed that way. With this case, we have an explicit discovery step that the client is missing - it'd be like sending an unknown IQ, therefore, not like additional elements within a message.

fair

I don't think I'd blame an implementation for ignoring them, but I think error is probably preferable.

I can't help but read that as "the implementation I wrote ignores them, but an error is probably preferable" ;)

TBH, I've no idea what we do :)

(fwiw Prosody probably ignores them)

Obviously the fault lies with the client, it's just a question of how easy we make it for client devs to debug what's wrong

I think if I was implementing it, I would make it ignore them, because that'd be the default without writing extra code and thinking about it.

Openfire now throws errors on non-empty, unrecognized fields.

Empty fields is another bundle of joy.

maybe we should add in xep guidelines "specify what to do with empty fields" (consider them as .. or sth)

What time do we think we'll get to Cisco on Thursday? 09:30 start?

I think we previously did 10.

last year, I traveled on Thursday morning. 10 was tight.

This year, I'll be in Brussels on Wednesday though, so it doesn't matter much to me.

Ejabberd returns errors if you include whit/start/end fields without values in the query and I was very confused about this until recently

Might be good to ask for more agenda items. Thanks nyco for adding a bunch.

I just did ask, in summit@

I have bought a load of post-its, marker pens, and dot stickers, so it's not too critical (though it's nice if people think in advance).

Gone trough the meeting introspection notes from previous years? :)

nyco: '... Xabbers approach seems good' do you have a link to that approach?

they are translating their XEP

Everyone: If you are coming to the Summit, but haven't added your name to https://wiki.xmpp.org/web/Conferences/Summit_24, please do!

ralphm, Guus - might be good to put the venue details on there too.

Oh, they are now, sorry!

nyco: just realized we haven't sent yesterday's minutes. I can't now, can you have a look? otherwise I'll do that tonight

sorry, no time, and moreover I did not follow correctly the meeting