moparisthebest, didn't you plan an update on https://xmpp.org/extensions/xep-0368.html security considerations after last week's discussions with SamWhited?
moparisthebest
Tobias, I updated it
Tobias
so it's just the editor that hasn't processed it yet, ok
moparisthebest
he wanted the description updated, and I changed something else too, I think it's good to go
moparisthebest
I think he did? I'll check
moparisthebest
yea that's the latest version
Tobias
ah..ok
SamWhited
I thought I merged… refresh?
Link Mauve
Hi~
Tobias
yeah..seems it's the latest version
Tobias
ah..seems it's about time
Tobias
1) Roll call
daniel
here
SamWhitednods
Dave Cridland
Here.
Link Mauve
Here too.
Tobias
great
Tobias
2) Minute taker
Tobias
seems jc isn't here, so we need a volunteer
daniel
i can do it
Tobias
great
Tobias
3) Outstanding votes
Tobias
https://trello.com/b/ww7zWMlI/xmpp-council-agenda there are 2 ProtoXEPs and 2 other voting issues on the trello, please see recent minute notes and reply on list to vote
Dave Cridland
I've a few there.
Tobias
4) Clarify CSI and Carbons state after SM resumption https://github.com/xsf/xeps/pull/402
Tobias
Sam added this earlier this month, Flow closed his PR and opened indepenent PRs instead. Please take a look and reply feedback in the PRs.
Tobias
5) The Last Call for XEP-0333: Chat Markers ended, daniel is taking maintainership and will probably send in an update sometime so we can vote on advancing it
SamWhited
If daniel plans on making more changes, I will extend the LC by another week.
Tobias
more changes? haven't seen changes since the LC was issued
SamWhited
s/more changes/changes/
Tobias
ah..k
Tobias
6) Vote on advancing XEP-0368: SRV records for XMPP over TLS, specifically Version 0.1.2, to Draft
Tobias
I'll vote on list
daniel
+1
SamWhited
I still don't like the direct TLS definition text, but that's an editorial change that can be made during draft
SamWhited
so +1
daniel
re extending the last call for xep333. please do. i will make changes in the next wee
Tobias
Dave Cridland, Link Mauve ?
Link Mauve
Wasn’t there a pending PR to fix the direct TLS definition?
Link Mauve
Apparently not.
Link Mauve
Anyway, will vote on list.
Dave Cridland
I think '368 is ready to go Draft now.
Tobias
that's probably supposed to be at least a +0
Tobias
?
Dave Cridland
+1
Tobias
great
Dave Cridland
FTR, I'm sure there's further editorial fixes, but the technical side seems solid.
Tobias
7) Date of next
Tobias
I'm probably traveling next Wednesday around this time
daniel
should we do tuesday?
daniel
same time?
Link Mauve
I’m ok with Tuesday.
SamWhited
WFM
Tobias
that could work better for me, yeah
Tobias
does that work for you, Dave Cridland?
ralphmhas left
Dave Cridland
I think so.
Tobias
great..that would be 2017-02-28 16:00:00 UTC then
Tobias
8) AOB
SamWhited
Yes
Tobias
yeah?
SamWhited
XEP-0233, 0280, 0334, 0352 had their LCs end today. One of them has a pending PR (0280), otherwise do we want to do anything about them?
Tobias
probably see what the feedback was on them, if there was positive feedback indicating that they are fine and no changes are required, we can vote on them next week
Tobias
if the feedback indicates changes are required, they should stay proposed until we receive an update on the XEP
daniel
334 and 352 are probably good to go
daniel
but we can vote on that next time
daniel
i think with these widely deployed xeps no feedback is good feedback
SamWhited
334 I'm a bit torn about, but I agree with 352
SamWhited
anyways, next week. In the mean time should I extend the LC or move them back to experimental?
Tobias
i'd request to extend the LC of XEP-0233 and i'll bug someone who implemented it to respond with feedback on the list
Kev
FWIW, I don't think that's true, 'no feedback' is generally a sign of no interest in XEPs, which implies they've probably not seen sufficient review.
Kev
(Not saying that's the case with 334/352 necessarily, but as a general point)
daniel
Kev, i was specifically talking about those day. as they seem to be used and implemented
daniel
s/day/two
Tobias
yup...and we should try bugging people having implemented those...even if they have little time they could simply reply with a mail answering the questions with a short Yes/No.
Link Mauve
Tobias, that sounds sensible.
daniel
ok
Tobias
any other AOB?
SamWhited
Sounds reasonable; in that case I'll extend the LCs again.
Tobias
SamWhited, sounds sensible
Tobias
doesn't look like it
Tobiasbangs the gavel
Tobias
thanks everyone
Link Mauve
Thank you!
Tobias
thank you daniel for writing up meeting minutes
moparisthebest
note with 368 I made a somewhat major change with the last version
jerehas joined
moparisthebest
SamWhited, pointed out 3.1 had no proper SHOULD/MUST etc language
moparisthebest
in my mind that was always a MUST (mixing priorities of records), but he and ralphm convinced me it should be a SHOULD
moparisthebest
so maybe it was only a major change in my mind :)
Tobias
will give the XEP a total reread this evening then :) luckily it's not that big
moparisthebest
yea and it works the same both ways, the server op can't tell if you mixed priorities or some ports were blocked
moparisthebest
so in the grand scheme of things, no big deal
ralphmhas left
jayaurahas joined
Dave Cridland
So it might be that there exist circumstances to not mix priorities properly, and it'll still interop? Feels like a SHOULD is OK here.
jcbrandhas joined
Dave Cridland
moparisthebest, What were the cases ralphm and SamWhited were unable to mix priorities?
moparisthebest
Dave Cridland, ralphm pointed to the python twisted lib that connected to SRV records and how it'd be hard to mix them, but easy to try xmpps-client first then xmpp-client second
moparisthebest
which is fair, and like you said doesn't affect interop, and moreover is invisible to the server
Zash
moparisthebest: I also believe that'd be easier to implement.
moparisthebest
right
Zash
Keeping track of 'this srv entry is with tls/with starttls' seems like a recipe for messing up
Dave Cridland
Zash, I found it easy enough, and RFC 6168 is the same, so it's not uncommon.
moparisthebest
it was easy in conversations
moparisthebest
you already have to keep an object with 'target' and 'port', throwing 'directTls' in there is trivial?
Dave Cridland
That's basically what I did in Metre.
Dave Cridland
It treats a _xmpps-server._tcp record as if it were a _xmpp-server._tcp record with an extra field of "tls=true".
Zash
I may have done somesuch for DANE
moparisthebest
conversations code starts about here: https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/DNSHelper.java#L184
moparisthebest
and yea I think you'd do DANE the same way, store the key hash on the same object
moparisthebest
I think, implementing dnssec+dane is fairly high on my priorities as a next patch for conversations
Dave Cridland
moparisthebest, See the minidns work that the XSF had s a GSoC project a couple of years back - should work fine. Smack uses it already.
Dave Cridland
moparisthebest, But just do DNSSEC+RFC 6125 names to beging with.
moparisthebest
yea Dave Cridland conversations already uses minidns, so I think it's basically just writing a bit of code
moparisthebest
so that brings up an interesting point, DANE can pin certs, public keys, and anywhere in the chain, but the RFC recommends implementations for a specific protocol pick one way and stick with it
moparisthebest
like for SMTP they just use public key pinning on the end device and that's all that is supported
jayaurahas joined
Lancehas joined
moparisthebest
sorry had to run off, but is there a standard like that for DANE with xmpp?
moparisthebest
or can/should we make one?
Dave Cridland
DANE-SRV is as close as we get. But I'm happy supporting all forms - I've seen use-cases for all of them.
moparisthebest
I despise certificate pinning personally hehe
moparisthebest
pinning the end devices public key is the only way to go in my opinion
Zashhas joined
SamWhited
Dave Cridland: I *can* mix priorities, I just don't want too. I'm going to try connecting and starting TLS and connecting and starting a plain stream at the same time probably; if TLS works, it wins, otherwise start using the plain stream that was already being negotiated.
Kevhas left
moparisthebest
attempting simultaneous connections sounds , not good for some reason
moparisthebest
do you do that now with existing SRV records? attempt them all at once and see which one wins?
SamWhited
moparisthebest: I'm not doing it for each record, just for each type of record (xmpp vs. xmpps); weights and priorities are still used within those records.
SamWhited
However, yes, if you have a few servers with identical weights and priorities, I would like to connect to all of them and use whichever one wins.
SamWhited
(and then if that fails, fall back to the next set of weights/priorities)
moparisthebest
what's the difference? the server op mixed priorities when they defined them
moparisthebest
I mean none of this really matters, you can do it however you like and interop and everything will work perfectly
SamWhited
If the server op made plain a higher priority than TLS, I'm ignoring it. That's basically the only difference.
moparisthebest
just seems strange, I assumed people that wouldn't mix them would just try xmpps- first, then xmpp-
Kevhas left
SamWhited
That's what I'm doing; doing it at the same time is just an optimization (if we can't do xmpps, we just fallback to the connection that's already started)
moparisthebest
yea but in doing both at the same time it's slower than just doing the first would be
moparisthebest
if bandwidth is constrained or anything
SamWhited
maybe, but I really doubt even the slowest connections are *that* slow (unless you're operating of HFR or something)
Kev
And no-one would do that, right? :)
SamWhited
Heh, I'm aware that it exists, I'm just not writing a library that aims to target every single use case (although, this will probably be an option when you configure the session, so it will probably support not doing it this way too, haven't figured the API out yet though)
jayaurahas joined
Dave Cridland
I was wondering about happy-eyeballs across multiple SRV records.
Kev
I think I've suggested before that happy-eyeballs across multiple same-priority records is sensible.
moparisthebest
how many domains have enough servers where it'd make a difference?
moparisthebest
that's a genuine question I really do not have any idea :)
ralphmhas left
SamWhited
I'm not sure; probably not many, but it's also not hard to do or anything, so I'm not sure that it matters. ¯\_(ツ)_/¯
jayaurahas joined
moparisthebest
it just kind of smells of premature optimization, multi-threaded code where connections are racing and one wins doesn't sound like the simplest thing to implement, especially if 99% of cases have 1 server anyway
SamWhited
Nah, I've already done it, it was trivial.
moparisthebest
probably depends a lot on the language too :)
moparisthebest
what are you using? go still?
SamWhited
Yah, Go (which indeed is the reason why it was trivial)
moparisthebest
is that code open source anywhere? I'd like to have a look
SamWhited
I just need to add it to my XMPP library and also add the XMPP/XMPPS version (although that's not a race, that's waiting on XMPPS and just pre-negotiating XMPP in case XMPPS fails)
moparisthebest
yea I was thinking about how to implement it in java, but I'm not sure I'd call it trivial
SamWhited
Nothing is trivial in Java… everything is harder than you expect it to be.