Minutes IETF103: hrpc
minutes-103-hrpc-00

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”