18:29:44 <sysrqb> #startmeeting Tor Browser Team Meeting 24 February 2020
18:29:44 <MeetBot> Meeting started Mon Feb 24 18:29:44 2020 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:29:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:29:52 * sysrqb updates pad
18:29:53 <boklm> hi
18:29:54 <mcs> hi to all
18:30:04 <pospeselr> hi
18:30:10 <brade> hi
18:30:19 <acat> hi
18:30:19 <sisbell> hi
18:31:32 <sysrqb> hi everyone
18:31:36 <Jeremy_Rand_Talos> hello!
18:31:47 <antonela> hello folks!
18:31:55 <sysrqb> Jeremy_Rand_Talos: I will reply to you today (maybe tonight)
18:33:04 <Jeremy_Rand_Talos> sysrqb, ok thanks.  (Hope I'm not pestering you too much about it, I know you have a lot of things to be doing)
18:33:14 <sysrqb> nope, just enough
18:33:32 <Jeremy_Rand_Talos> cool :)
18:35:55 * antonela the pad just in case https://pad.riseup.net/p/TorBrowserTeamMeetingNotes-keep
18:36:12 <sysrqb> ^^ :)
18:36:13 <sysrqb> thanks antonela
18:37:18 <sysrqb> okay, let's get started
18:38:15 <sysrqb> boklm: i'm available after this meeting for chatting with GeKo, if that works for you, too
18:38:23 <boklm> that works for me too
18:39:05 <sysrqb> great
18:40:00 <sysrqb> acat: how is the rebasing going? is it difficult? like, are there a lot of merge conflicts?
18:41:02 <sysrqb> pospeselr: have you had any time for reading through the recent-past Firefox release notes?
18:41:18 <sysrqb> i know you've been tied up with some other tickets, too
18:41:20 <acat> there are some, although i would say not in the most critical ones
18:41:21 <pospeselr> i haven't, been focusing on the S27 stuff
18:41:33 <sysrqb> acat: okay, that's good
18:41:35 <acat> for example, the updater ones applied mostly fine
18:41:40 <pospeselr> i can shift over if we're getting close on time
18:42:20 <sysrqb> pospeselr: okay. i'm really not sure how we should prioritise these
18:42:25 <sysrqb> pospeselr: stick with s27 right now
18:42:38 <sysrqb> acat: nice
18:42:43 <sysrqb> that is good news
18:43:31 <sysrqb> pospeselr: we don't need to finish reviewing the release notes this month, and obviously that won't happen
18:44:23 <pospeselr> i can skip over #33298 for now
18:44:24 <sysrqb> but i think we should prioritize finishing s27 tickets and then working on fixing the test suite
18:44:38 <pospeselr> since we only run into it very rarely compared to #13410
18:45:18 <sysrqb> #33298 is ugly though
18:45:28 <sysrqb> like, that is pretty bad
18:45:42 <sysrqb> hrm. okay
18:45:47 <pospeselr> true
18:45:51 <antonela> a pop-up?
18:45:58 <antonela> will add a ux-team label to take a look
18:46:03 <sysrqb> yeah, skip it for now and i'll keep it on our radar and we can squeeze it in somewhere
18:47:56 <sysrqb> okay, i don't have comments on anything else
18:48:18 <sysrqb> i'll just remind everyone that this is the last week before the peer feedback is due
18:48:24 <Jeremy_Rand_Talos> Regarding #13410, is there any interest and/or ongoing work on actually valiidating trust on certs for onion services, e.g. via a TLSA-style record in the onion service descriptor?
18:48:43 <sysrqb> nope
18:49:19 <sysrqb> We could do a SOOP-like check, if the CN or SAN contain a matching onion address, then it's good
18:49:41 <Jeremy_Rand_Talos> sysrqb, Any particular reason for not doing so?  Just lack of prioritization, or is there an argument for not doing so?
18:50:01 <sysrqb> but the threat model where we are concerned about MITM attacks against a TLS connection over an onion is pretty obscure
18:50:16 <sysrqb> *attack
18:50:26 <pospeselr> antonela: #33298 is for fixing the onion equivalent of this: https://mixed-form.badssl.com/
18:51:02 <sysrqb> Jeremy_Rand_Talos: also, this would be for onion address that (probably) don't have a domain name associated with them
18:51:29 <sysrqb> so I'm not sure where the TLSA-style lookup would happen
18:51:37 <sysrqb> like, within which database
18:51:38 <Jeremy_Rand_Talos> sysrqb, well, Whonix-style threat models where the Tor daemon is in a separate trust domain from the HTTPS server/client seems to be an example where it would make sense to validate TLS certs (though for that use case trusting the onion service descriptor isn't exactly sane)
18:52:47 <sysrqb> right, i agree the attack is practical (for some definition)
18:52:49 <antonela> pospeselr: yep
18:53:11 <sysrqb> Jeremy_Rand_Talos: but i don't know what that "check" looks like, in practice
18:53:52 <Jeremy_Rand_Talos> sysrqb, main reason I'm curious is that Namecoin makes that kind of validation interesting (i.e. put a TLSA record in Namecoin along with the TXT record for the onion service); trying to gauge if there might be some interest in the future in doing that in Tor Browser (in the hypothetical scenario that Namecoin integration is adopted)
18:55:10 <Jeremy_Rand_Talos> For pure onion services without Namecoin, I suppose some users might like to manually specify cert pins, but that's not something typical users will be expected to want to touch
18:55:13 <sysrqb> Firefox ripped out DANE support a while ago
18:55:25 <sysrqb> i don't see up re-implementing it anytime soon, to be honest
18:56:18 <sysrqb> i'm not opposed to this, and i think it has a use case
18:56:19 <Jeremy_Rand_Talos> sysrqb, yes, I know Firefox doesn't natively support DANE; Namecoin found a way to make it work again without any code patches to Firefox (subject to some limitations that aren't a problem for this use case)
18:56:37 <sysrqb> okay, that's interesting
18:57:02 <sysrqb> if we get support for something like this "for free" then it is worth considering
18:57:27 <sysrqb> but it is out-of-scope for #13410
18:57:56 <sysrqb> can you open a ticket for this?
18:59:05 <Jeremy_Rand_Talos> sysrqb, sure.  Should the ticket be specifically about doing it with Namecoin, or more generally about DANE-style stuff for Tor Browser, or even more generally about cert trust validation for TLS on .onion?
19:00:09 <sysrqb> Jeremy_Rand_Talos: open it for namecoin, and we can always repurpose it (or open other parent/child tickets), if that makes sense
19:00:14 <sysrqb> thanks
19:00:16 <Jeremy_Rand_Talos> (I assume that this is going to be much lower-priority than the Namecoin integration that's already in Nightly?)
19:00:32 <sysrqb> yes, that's probably true
19:01:47 <Jeremy_Rand_Talos> ok.  I'll open a ticket about it, with the assumption that we won't worry too much about it until/unless the existing Namecoin integration advances some more
19:02:09 <sysrqb> that's fair
19:02:22 <sysrqb> we can always reprioritize later
19:03:05 <sysrqb> okay, i don't have anything for this meeting. do any of you want to discuss any other topics?
19:03:28 <sysrqb> otherwise i'll end this
19:03:36 <sysrqb> *anything else
19:04:18 * sysrqb hears nothing
19:04:51 <sysrqb> ciao o/
19:04:57 <sysrqb> #endmeeting