18:29:44 #startmeeting Tor Browser Team Meeting 24 February 2020 18:29:44 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:29:52 * sysrqb updates pad 18:29:53 hi 18:29:54 hi to all 18:30:04 hi 18:30:10 hi 18:30:19 hi 18:30:19 hi 18:31:32 hi everyone 18:31:36 hello! 18:31:47 hello folks! 18:31:55 Jeremy_Rand_Talos: I will reply to you today (maybe tonight) 18:33:04 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 nope, just enough 18:33:32 cool :) 18:35:55 * antonela the pad just in case https://pad.riseup.net/p/TorBrowserTeamMeetingNotes-keep 18:36:12 ^^ :) 18:36:13 thanks antonela 18:37:18 okay, let's get started 18:38:15 boklm: i'm available after this meeting for chatting with GeKo, if that works for you, too 18:38:23 that works for me too 18:39:05 great 18:40:00 acat: how is the rebasing going? is it difficult? like, are there a lot of merge conflicts? 18:41:02 pospeselr: have you had any time for reading through the recent-past Firefox release notes? 18:41:18 i know you've been tied up with some other tickets, too 18:41:20 there are some, although i would say not in the most critical ones 18:41:21 i haven't, been focusing on the S27 stuff 18:41:33 acat: okay, that's good 18:41:35 for example, the updater ones applied mostly fine 18:41:40 i can shift over if we're getting close on time 18:42:20 pospeselr: okay. i'm really not sure how we should prioritise these 18:42:25 pospeselr: stick with s27 right now 18:42:38 acat: nice 18:42:43 that is good news 18:43:31 pospeselr: we don't need to finish reviewing the release notes this month, and obviously that won't happen 18:44:23 i can skip over #33298 for now 18:44:24 but i think we should prioritize finishing s27 tickets and then working on fixing the test suite 18:44:38 since we only run into it very rarely compared to #13410 18:45:18 #33298 is ugly though 18:45:28 like, that is pretty bad 18:45:42 hrm. okay 18:45:47 true 18:45:51 a pop-up? 18:45:58 will add a ux-team label to take a look 18:46:03 yeah, skip it for now and i'll keep it on our radar and we can squeeze it in somewhere 18:47:56 okay, i don't have comments on anything else 18:48:18 i'll just remind everyone that this is the last week before the peer feedback is due 18:48:24 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 nope 18:49:19 We could do a SOOP-like check, if the CN or SAN contain a matching onion address, then it's good 18:49:41 sysrqb, Any particular reason for not doing so? Just lack of prioritization, or is there an argument for not doing so? 18:50:01 but the threat model where we are concerned about MITM attacks against a TLS connection over an onion is pretty obscure 18:50:16 *attack 18:50:26 antonela: #33298 is for fixing the onion equivalent of this: https://mixed-form.badssl.com/ 18:51:02 Jeremy_Rand_Talos: also, this would be for onion address that (probably) don't have a domain name associated with them 18:51:29 so I'm not sure where the TLSA-style lookup would happen 18:51:37 like, within which database 18:51:38 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 right, i agree the attack is practical (for some definition) 18:52:49 pospeselr: yep 18:53:11 Jeremy_Rand_Talos: but i don't know what that "check" looks like, in practice 18:53:52 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 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 Firefox ripped out DANE support a while ago 18:55:25 i don't see up re-implementing it anytime soon, to be honest 18:56:18 i'm not opposed to this, and i think it has a use case 18:56:19 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 okay, that's interesting 18:57:02 if we get support for something like this "for free" then it is worth considering 18:57:27 but it is out-of-scope for #13410 18:57:56 can you open a ticket for this? 18:59:05 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 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 thanks 19:00:16 (I assume that this is going to be much lower-priority than the Namecoin integration that's already in Nightly?) 19:00:32 yes, that's probably true 19:01:47 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 that's fair 19:02:22 we can always reprioritize later 19:03:05 okay, i don't have anything for this meeting. do any of you want to discuss any other topics? 19:03:28 otherwise i'll end this 19:03:36 *anything else 19:04:18 * sysrqb hears nothing 19:04:51 ciao o/ 19:04:57 #endmeeting