14:59:05 <antonela> #startmeeting S27 02/11
14:59:05 <MeetBot> Meeting started Tue Feb 11 14:59:05 2020 UTC.  The chair is antonela. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:05 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:10 <antonela> hello
14:59:11 <asn> o/
14:59:26 <asn> greets
14:59:26 <pospeselr> o/
14:59:30 <dgoulet> o/
14:59:32 <antonela> our meeting pad here https://pad.riseup.net/p/s27-meeting-keep
15:00:08 <brade> o/
15:00:20 <acat> hello
15:00:39 <mcs> hi
15:00:40 <antonela> pili is not online today but lets have this meeting to sync about updates and whatever needs to be discussed
15:01:39 <asn> antonela: wanna run the meeting?
15:01:48 <asn> should i try? how do we play it?
15:01:57 <antonela> haha yes
15:02:03 <antonela> i think updates are in the pad
15:02:07 <antonela> so lets move to discussion items
15:02:13 <asn> ack
15:02:35 <antonela> we have some tickets that need review
15:02:40 <antonela> #19757
15:02:59 <antonela> pospeselr or acat, could one of you take this review?
15:03:17 <mcs> note that it is a second review without too many changes :)
15:03:26 <antonela> :)
15:03:30 <mcs> (since the previous patches)
15:03:42 <pospeselr> i'll take a second look :)
15:03:47 <antonela> thanks pospeselr!
15:04:03 <antonela> after this review, will we have it in some nightly mcs?
15:04:39 <mcs> that is up to sysrqb (when he merges it). but we can make sure he knows we want to see it soon
15:04:57 <antonela> cool, we will ping sysrqb later so :)
15:04:59 <antonela> #21952
15:05:38 <antonela> matt has been reviewing it, but not sure if is done or not
15:05:39 <antonela> acat?
15:07:27 <antonela> next one is pospeselr's #32645
15:07:39 <acat> it might need some revision, but not completely sure tbh
15:08:02 <pospeselr> mine will definitely need revision, did some testing yesterday and not getting the right icon in certain scenarios
15:08:28 <pospeselr> but should hopefully have fix(es) up today or tomorrow depending
15:08:31 <antonela> acat: are you waiting for matt? or do you need to push before next review?
15:08:44 <antonela> pospeselr: nice, maybe mcs/brade can review it
15:08:53 <sysrqb> (whoops)
15:09:36 <antonela> hello :)
15:09:44 <pospeselr> after that i'll move on to fixing the problem where we get those WARNING splash screens (I forget the ticket number but it's a child off of 32645's parent)
15:09:49 <mcs> brade and I can review the fix for #32645 (we will wait for rev2)
15:10:27 <antonela> thanks mcs and brade!
15:10:32 <antonela> pospeselr: do you mean childs of #30025?
15:11:06 <pospeselr> yeah i think so
15:11:10 <pospeselr> one sec i can find it
15:11:14 <sysrqb> i didn't start looking at the patch for onion-location, i only commented on the plan/proposal
15:11:38 <sysrqb> but i should look at the code, and we can think about getting it into nightly
15:11:44 <sysrqb> builds
15:11:52 <antonela> sysrqb: nice
15:12:21 <antonela> pospeselr: we can talk about O2A4 child tickets now, which is the next discussion item
15:13:01 <antonela> we have a few child tickets there and could be nice if we discuss what can be done and what not considering the timeframe we have
15:14:06 <asn> aha
15:14:20 <antonela> #13410
15:15:03 <asn> just for some additional context, we talked with the people handling the onions of some big orgs the other day, and all of them mentioned that the SSL cert situation is very troublesome for them
15:15:09 <pospeselr> yeah that's the one
15:15:25 <asn> both because they need to pay for the EV cert, and also because it's a big procedure for them applying for certs
15:15:33 <asn> so this self-signed business becomes more important
15:15:45 <sysrqb> i think this is doable
15:15:46 <asn> i'm wondering what's your plan with the SSL parts of O2A4
15:16:03 <sysrqb> asn and i chatted yesterday about what we can accomplish during the s27 timeframe
15:16:26 <sysrqb> there are two general ideas for this
15:16:37 <sysrqb> one is likely significantly more difficult than the other
15:17:04 <sysrqb> 1) ignore tls warnings when the cert is for an onion address
15:17:33 <sysrqb> 2) treat tls certs that are signed by the onion service key as CA-signed (or something to that dffect)
15:17:37 <sysrqb> *effect
15:17:58 <sysrqb> (2) is likely an invasive change within necko and maybe nss
15:18:08 <sysrqb> (1) seems potentially dangerous but easier
15:18:45 <sysrqb> we'd need to be sure we catch any edge cases with (1), else we break tls security in tor browser, which would be...not so good
15:19:13 <asn> i'm not sure if (1) is any more dangerous than (2) for realistic threat models
15:19:14 <sysrqb> but, to asn's question, we didn't really have a plan until yesterday
15:19:26 <sysrqb> asn: could be
15:19:49 <asn> because it seems like (2) protects against some esoteric attacks, but both (1) and (2) allow people to do SSL with self-signs basically
15:19:55 <pospeselr> what are the concerns with doing (1) ?
15:20:03 <pospeselr> like how is it particularly dangerous?
15:20:35 <asn> can somoene take this question?
15:20:43 <sysrqb> asn: i think i see (2) as less dangerous because it has a narrower scope - only if the cert is signed by the onion service key
15:20:45 <asn> i can give handwavey answer if needed
15:21:28 <sysrqb> whereas (1) results in a valid certificate if the cert includes the onion address
15:21:42 <asn> i'm worrying about "attacker wants to impersonate FB. makes fake FB onion and corresponding onion-signed cert. points user to fake FB. user checks SSL indicators and think that they are secure because SSL is there and no warnings"
15:21:42 <sysrqb> in practice, maybe they're basically the same
15:21:47 <sysrqb> which is maybe your point
15:21:50 <asn> this attack neither (1) or (2) fixes
15:22:03 <sysrqb> right
15:22:05 <asn> but i'm not sure if this attack is in the threat model. that is, if users actually look at SSL indicators
15:22:12 <asn> or if they should be looking at them
15:22:34 <sysrqb> yeah, there isn't any validation and phishing is easier than before
15:23:15 <pospeselr> oh i see
15:23:16 <sysrqb> pospeselr: my concern with (1) is missing an edge case and allowing an invalid cert on a non-onion site when it shouldn't be allowed
15:23:45 <pospeselr> alright i'll keep that in mind
15:23:59 <sysrqb> as in, decreasing the security notion of TLS on the internet while decreasing warning fatigue on onion sites
15:24:30 <sysrqb> but phishing is already an unsolvable problem
15:24:56 <sysrqb> (in terms of what we have available today)
15:25:01 <antonela> right
15:25:17 <sysrqb> so i don't think the threat of phishing should prevent us from doing this
15:26:39 <sysrqb> in any case, my feeling is that (1) is something we can implement within the next month or so
15:26:53 <sysrqb> and (2) would likely take more time than that
15:27:20 <sysrqb> plus tor will need to learn how to sign a tls cert
15:27:50 <asn> https://github.com/ahf/onion-x509
15:27:55 <sysrqb> (maybe that only means it needs to accept a tls cert via commandline because it already signs certs internally)
15:27:56 <asn> this is a related project  from ahf ^
15:28:00 <sysrqb> oh ho
15:28:16 <asn> but i think ahf told me that firefox esr does not support ed25519 ssl sigs?
15:28:22 <sysrqb> oh, alrighty
15:28:42 <sysrqb> oh, hrm. i don't know
15:29:18 <sysrqb> i heard it may take a long time before browsers start accepting ed25519 sigs
15:29:23 <ahf> there is an onion address somewhere on that github readme that don't work - it might be my stuff that don't work or it might be missing ed25519
15:29:29 <sysrqb> but i haven't looked into it
15:30:21 <sysrqb> no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
15:30:47 <sysrqb> hrm. yeah. okay, that's another reason for ignoring (2) right now
15:31:47 <sysrqb> pospeselr: you'll start looking at this?
15:31:51 <mcs> is (1) covered by #13410?
15:32:09 <pospeselr> mcs: yeah I think so
15:32:21 <antonela> cool, so we have a plan
15:32:21 <mcs> or is it broader than just ignoring self-signed warnings?
15:32:22 <asn> yes i think so too
15:32:25 * antonela kind of
15:32:38 <dennis_jackson> How would mixed-content warnings function if 1) was deployed?
15:32:54 <sysrqb> o/ dennis
15:33:08 <dennis_jackson> o/ (sorry for diving in with a question)
15:33:14 <sysrqb> np :)
15:33:23 <antonela> hi dennis_jackson
15:33:25 <pospeselr> so for #32645 mixed-content warnings happen when an onion resource embeds non-onion resources
15:34:29 <sysrqb> dennis_jackson: are you imagining the top level context was created over a tls connectoin from a (would-be) invalid cert
15:34:32 <pospeselr> via the onion+warning icon in the toolbar
15:34:40 <sysrqb> and that contains a resource loaded over http?
15:35:05 <asn> fwiw tons of work was done on this here: https://trac.torproject.org/projects/tor/ticket/23247#comment:20
15:35:15 <dennis_jackson> I am also wondering about how trust relationships between domains and subdomains play with different onion services
15:35:16 <asn> including expectations and icons etc.
15:35:24 <sysrqb> dennis_jackson: or top-level context is from a valid tls-cert connection and subresource is from a (would-be) invalid tls cert connection
15:35:29 <asn> isabela and tjr also helped back then
15:37:44 <antonela> so, we also have #27636 and #30937 listed as a child
15:37:46 <sysrqb> dennis_jackson: i think the answer depends on the scenario you're imagining
15:38:31 <sysrqb> i think the plan is that #30937 is covered by #13410
15:39:08 <antonela> great
15:40:02 <dennis_jackson> sysrqb: Fair enough, I will go and read the various tickets and have a think
15:40:32 <sysrqb> antonela: tom's comment on that ticket is interesting, though
15:40:36 <sysrqb> " I had thought that SSL certs that cause errors should not cause an intersitial error; but they also should not get the Onion+Lock icon (and only the Onion icon.) "
15:40:50 <sysrqb> the end part, in particular
15:41:16 <antonela> it is, yes
15:41:42 <sysrqb> i think I agree
15:41:58 <pospeselr> a bit of a moot point, as onion+lock doesn't exist anymore after #32645
15:42:02 <antonela> i think most of the discussion around which escenario should have which icon happened during #23247 - now we are iterating over it, not over the behaviour (mostly) but over the UI
15:42:14 <antonela> and yes, onion+lock doesnt exist anymore
15:42:40 <sysrqb> Mmm true
15:42:49 <sysrqb> okay, good. carry on :)
15:43:20 <antonela> other child tickets are UI related so i think we are good: #27657
15:43:31 <antonela> and #26491
15:43:44 <antonela> so, pospeselr will work on *all* this stuff?
15:43:57 <mcs> are we planning to fix all of those for S27? what can we defer?
15:44:05 <antonela> exactly, that is the question
15:44:16 <dgoulet> I believe the bottom line is: s27 ends in April ?
15:44:27 <sysrqb> we can't finish all of these tickets
15:44:33 <antonela> yes it ends in April
15:45:07 <brade> I thought it ended March 31
15:45:12 <sysrqb> mostlikely we'll only work on sponsor27-must tickets
15:45:28 <dgoulet> brade: yeah April 1st or March 31st, correct
15:45:31 <asn> yes march 31st indeed
15:46:05 <antonela> i dont think is a problem for otf to give an extension, but is pili who is running estimations and roadmaps
15:46:20 <brade> we don't have cycles for an extension
15:46:30 <antonela> what it means?
15:46:44 <sysrqb> unfortunately because we're migrating to Release cycle
15:46:57 <antonela> i see
15:47:08 <antonela> mmm okey
15:47:08 <sysrqb> we don't have enough people for working on both s27 and the migration after March
15:47:16 <antonela> maybe is something to discuss with pilar when she is back
15:47:45 <sysrqb> yeah. i'll discuss this with her
15:47:51 <antonela> anyways, we are close to the hour
15:47:56 <antonela> anything else folks?
15:49:13 <mcs> I would say #30090 can be closed
15:49:19 <antonela> ahh thanks!
15:49:34 <antonela> cool, will do it -- i wonder if we need some sort of documentation about it or if it is already done
15:49:35 <mcs> unless something did not make it into the tor docs (but I think everything did or will once final patches land)
15:49:40 <antonela> perfect
15:49:44 <antonela> will close that one then
15:50:00 <mcs> asn or dgoulet can confirm :)
15:50:09 <asn> i think it's good yes
15:50:51 <antonela> great
15:51:27 <mcs> there is also this discussion point: Should we contact SecureDrop folks to start setting some specs about the rulesets we need?
15:51:36 <mcs> I am not sure what that refers to though
15:51:43 <antonela> it is related with O2A5
15:51:53 <antonela> https-e and onionnames
15:51:54 <asn> this might be a good idea tbh
15:51:54 <mcs> ah
15:52:08 <asn> acat wanna use that thread we started to establish some contact with jenn?
15:52:56 <acat> ok, but what do we need to ask for exactly?
15:53:27 <asn> i guess we should tell them that in X weeks we will ask them for precise rulesets?
15:53:30 <asn> or for an update channel?
15:53:33 <asn> and how they envision it?
15:53:36 <asn> or how we envision it
15:54:43 <acat> ok, i assume asking for an update channel is reasonable, in a way that we can scope it to *.securedrop.tor.onion
15:54:50 <asn> right
15:54:53 <asn> exactly
15:55:29 <acat> good, will do
15:55:46 <antonela> cool
15:56:24 <antonela> i added a question about the nightlies but maybe we can talk about them next week once more patches are reviewed
15:56:55 <antonela> (i'll be traveling next week, so might miss this meeting)
15:57:02 <antonela> i think that is all then
15:57:06 <mcs> antonela: thanks for running the meeting today
15:57:16 <antonela> no problem, thanks for being around!
15:57:40 <dgoulet> o/
15:57:47 <antonela> thanks all!
15:57:52 <antonela> #endmeeting