HRPC I, 2018-11-05 09:00:00+0700 (notes dkg) -------------------------------- # Welcome and introduction (Avri) # Talk by Arthit Suriyawongkul, Thai Netizen Network Freedom of Assembly and Association Online Jon Hoyland, Royal Holloway: a more common technique than fear is flooding -- just provide a lot of alternative content to prevent finding the relevant content. The list of rights in this presentation is lacking, because it doesn't address this kind of attack. Arthit: this might be more something that the platform provider needs to handle. Youtube has this issue, not for any HR concerns, but because it degrades the service they're trying to provide Jon Hoyland: perhaps HRPC wants to research this? Arthit: during a protest, we've seen police play loud copyrighted music, so footage of the protest gets taken down by facebook/youtube because of automated copyright takedown filtering. Ted Lemon: the documents i've read in HRPC i've read seem to focus more on a world that looks like the 1970s. we need to be more up-to-date. Attacks like the one that you describe are very clever -- we need to be addressing these sort of intersections between modern/novel complex technical systems. Avri: this is a problem that we're getting into on the list -- are we talking about how some application is used? or are we talking about what a protocol allows or disallows Nalini Elkins: I agree with Ted. So many new things are possible, and we need to be addressing what's coming in the future, not just what's happened in the past. Ted Lemon: (resp. to Avri) the difference between applications and protocol is distinct, but examples of specific applications inform the protocols. for example, many of the application mechanisms layered atop SMTP are there because of design characteristics of SMTP. We need our documents to reflect concrete problems, and not castles in the air. Brett Jordan: we've done a good job at encrypting traffic, but does that work end up creating stronger tracking mechanisms that can be used by the endpoints to track users? now that the channel is unimpeachable and clean, can the remote host track users more easily? # Talk by Ashwin Jacob Mathew, UC Berkeley (remote) Trust in Protocol Design Ted Lemon: it looks like we have a hobson's choice for BGP, between a system that doesn't work well (though it does work surprisingly well), and another system that might work better in some situations, but maybe worse in others. how do you suggest we choose that path? Ashwin: hard question; i don't have answers. accountability has largely been social, and it has worked so far, but there are other attacks that we don't know whether we can deal with, whether it's the pakistan Youtube attack, or other more modern attacks we don't know. But the stakes have gone up, and we need to. Kaveh Ranjbar: i have multiple issues -- you've mixed layers that are supposed to be separate. BGP is decentralized, and it is supposed to be. but then if you draw conclusions from BGP to DNS or ICANN, those are centralized so their structure doesn't match. we need to look at them separately. If tomorrow there is no ICANN, or even no DNS, nothing will change the routing. We need to make sure that the layers are considered separately. Ashwin: i agree -- i was not trying to imply that DNS and BGP are the same thing -- i just used DNS to illustrate a point. While the protocols are different, the communities often overlap. Do people trust ICANN? I'm offering one way that people do trust ICANN -- that they don't trust the institution, rather they trust some individuals that they know. there are different ways of managing trust. Kaveh: people created ICANN specifically so that they didn't need to trust an individual. we should talk about it more. Ashwin: remember ICANN was created by the USG. Ashutosh Singh (symantec): This discussion is missing the issue of legacy systems. Trust isn't all happening among homogenous systems. There will be legacy windows 95 machines or medical devices connected to the internet for a long time. Ashwin: agreed. Tara Tarakiyee (OTF): regarding the shift of BGP's RPKI from trust to assurance: Can this instead be seen as a shift from interpersonal trust to trust in cryptography and algorithms -- trusting the the small community of people who design the crypto and algorithms? Ashwin: maybe, but it might also be closer to a shift in trust to the certifying authorities of the RPKI, rather than just in the crypto+algorithms. Other systems, like "blockchain" rely more on trust in communities that develop the algorithms and crypto. # Update from the Hackathon (15 minutes) during discussion of DOH: ekr: you'll find it easier to analyze if you collapse all the secure channels (DoH, DoT, DoQ, dnscrypt) into a single bucket. they're roughly analogous Niels: we're triyng to evaluate the differences -- if the answer is that they're all the same, that's fine output -- please contribute to the analysis. mnot: please help me understand the chart here Martin Thomson: people conflate DoH with mozilla's choice of DoH+cloudflare, because the question of who chooses the resolver really changes the dynamics of the system overall. Eliot Lear: I think this is a pretty good slide as a way to start. we need to analyze these things someplace, and the first column addresses Martin's coments # Update from the Human Rights Review Team (15 minutes) presented QUIC review. Lars: You didn't get feedback from the QUIC list because it seems far down on the priority list Mirja Kuhlwind: i gave private feedback, but some of the issues you discuss there aren't clearly discussed in the draft. some issues are presented in a biased way, and that doesn't reflect well on the draft -- it doesn't describe what happened in the WG, and it dosen't add to the discussion much. Niels: do you think the relationship between HR and protocols isn't clear, or do you think we didn't map it well enough? Mirja: the framework is fine, but the draft doesn't really apply it as well as it should. But what has worked better is that people come to the QUIC WG and raise the HR concerns there -- and that is what happened, which is good. but then it raises the question of what the value of the draft is. Also, with interviews, you have a problem because you might have a smaller set of reflections about what happened. ekr: i read this, but it seemed disconnceted enough from the work of the QUIC WG. Some of the details are wrong (which i didn't have the energy to correct), and some of it has more to do with protocols generally (e.g. i18n) and not about QUIC. i was puzzled by this. Niels: QUIC has more people in the WG, the WG has more capacity than other smaller WGs ekr: the right way to do this is to show up at the WG and engage with the ongoing issues. Martin Thomson: i was an interviewee. Interviews were a good way to bootstrap the knowledge exchange between HRPC community and QUIC WG. so the process is a good start, but the end came doesn't need to be just a document or draft -- a better endpoint might be engagement in the WG. I do appreciate that there's a validation of some of the design choices we made in the WG. An e-mail to the QUIC WG that describes what we think was done well, and has reasons why it matters is really helpful feedback to the group. Alyssa Cooper: in the process of writing RFC 6973, the sec area ADs tried to create a privacy review team. we really do think that having experience with integrating with the WG is more effective. # Research Group drafts updates/discussions (20 minutes) draft-irtf-hrpc-association draft-irtf-hrpc-political draft-irtf-hrpc-guidelines Stephen Farrell: what does "Outcome transparency, arhchitecture, and power" mean? if you think these reviews should state who in an IETF context has power over who else, i think that's going to end badly. Ted Lemon: i'd like to see more discussion about the tensions between the rights. I don't think we've explored that enough. Also, i think the documents aren't currently accessible to people who aren't already invested in the topic. I'd like to see them be more useful as an introduction. Eliot Lear: would it be useful to have an ad hoc discussion this week to discuss how to move the drafts forward? Mallory: Avri and i as chairs should help Niels get this through. # Updates/discussions on drafts yet to be adopted by the RG (5 minutes) draft-elkins-hrpc-ifilter Nalini Elkins: the right to live is in conflict with the right to speech and the right to privacy. Avri: does this get into protocol considerations, or is this more about other concerns? # Open Discussion (15 minutes) (Meeting time ended, commitment to finding a time later in the week to schedule an HRPC II session.) HRPC I, 2018-11-08 14:00:00+0700 -------------------------------- # Introduction, tone setting and explaining we needed this extra meeting to talk about open questions on the agenda: Charter Drafts # Charter Chair A: Do we want to stretch out beyond ietf? We have 8280, we have done reviews. And in some sense, this was the first part of the experiment. We are still IRTF. But if the IETF wants to adopt us, they need to. We would need a WG to figure that out. How do we take 8280 and build a report on it, like an RFC, or a journal article. And how do we look at how different human rights interact. Nalini: Very interesting. Offers that she is willing to work on: Tension between rights kind of work Maybe with case studies & precedents But needs a group of people to work with Chair M: Can you clarify, if you want to look at tensions between rights or between protocols and rights? Nalini: Sometimes it’s about business Yes – want to work on the tensions where rights come into tension in protocols Niels: Case building would be good, let’s use the reviews for that And use that to update the draft guidelines Who is the audience of the academic article? Chair M: Added benefit of IRTF is that they can be mutually helpful Not that many people working on human rights at these layers, that is our contribution Try to be leaders in this area Nalini: Numbers on things would be good, also to get academics involved AA: Have been working on the bigbang mailinglist but we don’t have a lot of reviews again Chair A: It’s also about the methodology of human rights, we also have to do work on the methodology Some people really liked the reviews, others did not. We need more analysis on the process and the methodology. AA: Can Avri please pick up with the IAB, need clarification on how to deal with reviews from a group like this all the RGs go through periodic review, maybe we should volunteer HRPC for that David: have you done user research, profiling, or use cases? Have we tried to talk to protocol designers to understand the considerations of people on the ground? Maybe we need to provide profiles of the kind of users we want to address? In a generic way? Chair M: We are asking implementers to try? Good suggestion (profiles) 8280 is a broad overview, and the draft_association you are constraint by a broad scope. Maybe in future work we could drill down, like the presentation by Art. Chair A: We don’t do that jump to the humans down the line We focused on the abstract, human rights as defined and described, and not focus on the users or particular groups. Nalini: In other groups I do hear people say things about how protocols impact particular groups, but they lack numbers Chair A: Numbers are problematic, the counts of things can be confusing. Bennet: Does it make sense of human rights reviews of established RFCs? Maybe we need to brainstorm some rfcs Chair M: Thanks for bringing that up. I am also not hearing any issues around charter creep. There were some suggestions for further work or that we were not focused on the right things. Need to recommit to the charter, and a document that lays out what exactly we want to do (more reviews, numbers, improve guidelines) So we can create a list of things that people can do. NtO: Need numbers, methodology, test it – need to do more reviews, which will lead to more numbers, which will update the guidelines. Nalini: If we are serious about the tensions between rights, then we should make that a little bit more clear. Charter is pretty narrow, focuses on FOE and FOA. Lemons: It reads that those are the areas most relevant to the IETF. Chair M: We need to become better at mile-stoning. Path forward for existing drafts. When it comes to feedback, chairs have the role of giving feedback (you need to give substantive feedback) or allow for others to give substantive feedback and help improve the drafts on that basis. Chair A: Adopting something does not mean we are ready for it RFC is archival document - maybe there is more we can do Chair M: Maybe some stuff goes into an RFC some of it goes into a journal – that’s fine Juliana: Does the group of a code of conduct? Data is neutral, algorithms are not neutral, and how they look depends on who builds them. Chair A: We focus on protocols not the institutional behavior Shivan; So what do we do about the drafts? Niels: Tell me what to do (milestones), more reviews, whatever. # Drafts Chair M: Draft_Political (it’s tricky, tricky, tricky and subject of much discussion during meeting) Draft_Association Draft_annonimity (expired but should be picked up) Feminism draft (not in existence yet but there is will) Guidelines (will probably hold on those) Human rights review ‘thing”