Draft report on IETF89 PM review lunch meeting report
Avri Doria <avri <at> acm.org>
2014-03-12 10:19:51 GMT
Draft Meeting report.
A set of notes created by Scott Brim (thanks!) can be found at:
Those who were at the meeting should feel free to add their comments. A
text view of their current state is attached to this message.
In terms of the meeting, we discussed several issues and I believe we
came up with the following:
- Volunteers will be begin to work on reviews of existing standards
- While the reviews will be primarily for Pervasive Monitoring (PM)
risks and issues, privacy issues will also be in scope for the reviews.
- Several Protocols were given as first examples including;
-- DNS (there are already some reviews in circulation)
-- DHCP (There is already an review i this area)
-- URI usage
-- yet to be selected from the INT area
There is a long list of things to be reviewed. Stephen Farrell agreed
to check with other ADs on any particular recommendations they might
have on docs to be reviewed.
- There are several volunteers for this work listed in the meeting
notes. Several volunteers came forward later. This will be tracked on
the wiki once it is set up.
- An initial milestone of 15 May was set for some of the reviews.
- We had a discussion of some of the review work that had been done. It
was the feeling of the group that while we should be collecting a set of
bases for PM reviews, we would build on the work done for privacy
including RFC6973 Questionnaire. Creating a criteria set for PM
reviewing would be an ongoing project. There was discussion on the
utility of prioritizing or categorizing the PM and Privacy concerns.
- While the group did not decide to work on reviews of current drafts,
there was a spirit of cooperation on the work being done by Gen Art.
This needs follow-up.
- There was a decision to use the ietf-privacy email list for this work
instead of the perpass list. This is being sent to ietf-privacy and
then forwarded to perpass, but we should probably try to limit
discussion to the ietf-privacy list if at all possible.
- I will work to coordinate activities Using an IETF WIki. this Wiki
has been setup, <http://trac.tools.ietf.org/group/ppm-legacy-review/>
but I have not done anything with it yet. Still learning this flavor of
wiki, but will have some first pages soon. Eg. will put thse notes and
the meeting notes on the wiki.
26 People signed the not quite blue sheets.
There are two ways to review existing work:
* Issue areas
* Some STRINT contributions
* Specific RFCs (or drafts)
* http://tools.ietf.org/html/rfc6740 - ILNP architecture
Anyone want to talk about their own work or planned work?
Christine Runnegar: how to coordinate work across organizations eg W3C.
Robin Wilton: bridge the gap between technical people and social/policy people.
Alex Mayrhoftsh: Privacy in DNS. Make privacy comfortable for users.
Stephan Bortzmeyer: DNS and privacy.
Steve Olshansky representing ISOC.
Existing vs new documents? -> Let gen-art and SAAG look for privacy issues as part of their current review
process, and this is a new activity.
* Scott Brim: But consolidate results.
* Steve Kent: continue work on the threat document, and have a list of goals dealing with pervasive
monitoring eg data minimization, and for new documents require someone with a standards track document
refer to _prioritized_ list and say which ones they believe they have addressed.
* Brian Carpenter: adds to gen-art “please be sure this gets a security review” - Stephen says it’s
about an 80% rate -
* Brian says if something smells like privacy, flag it as needing a privacy review.
* Steve Kent: prioritization should be detailed, a total ordering - if you don’t do the first tier, the
rest is irrelevant. If I’m not encrypting the traffic, minimizing identifier use is not so important.
* Allison: we tried to do SIP privacy and thinks of data minimization as related to persistent object
security … missed it … Steve: in the context of the workshop, thinking of doing it on a per-layer basis.
* Alissa: analysis of the threats in surveillance draft could be complementary to the 6973 questionnaire
which is mostly about minimization.
* Steve: for existing docs get people who wrote them to tell you what they thought.
* Wendy Seltzer: pieces that look like risks in one context are not in another, so might characterize the priorities.
* Christine Runnegar: Do it early. Need volunteers with cross expertise. Learn by doing.
* Robin Wilton: going back to review old documents is good practice.
* Hannes: Collision with business model. Brian Carpenter: We could refuse to publish docs with
* Doug Otis: Assumptions about layers handling things.
* Linus: one person’s security conflicts with another person’s security i.e. bank transaction
monitoring to avoid fraud. Stefan Bortzmeyer: a privacy review doesn’t need to make choices like that,
just to make people aware of consequences.
* Steve Kent: early reviews can be requested.
* Alissa: for reviews of new protocols, need sector reviews, and the goal is to get things changed.
* Hannes: Host identity work. IntArea. A TCP option.
* Doug Otis: synthetic domains that identify you but are not part of the transfer. The protocol doesn’t
change but the deployment changes to make it more invasive.
* Wendy Seltzer: the function of the reviews could be both changes of protocols and deployment guidelines.
Wiki: Avri will gather from the list and will talk to Henrik about a wiki. Which list? ietf-privacy.
Doug Otis: marine tracking.
Allison: if you want to make it broader, ISOC 360 can help.
If you mail to an author and CC the list, need a manager for the list, for non-member mailings. Allison
volunteers to manage the list.
Including the wider privacy concept?
* We already have 6973, there will be overlap with pervasive monitoring.
* Allison: separate perpass from other privacy, but if you see perpass issues, flag them.
* Alissa: how much of an additional review will a pervasive monitoring review be? If not bad, do it.
* Stephen thinks the task is more tractable if focus just on pervasive monitoring.
* Brian but we have 6973 for privacy and no guidelines for pervasive monitoring yet.
* Elwyn: there’s quite a lot of inter-layer interactions with these things, and need to understand the
_context_ (lower layers) in which a protocol is used to understand its issues. So maybe start reviewing at
the bottom of the stack. Karen O’Donoghue: need prioritization.
* Alissa: to take best advantage of the current situation, for existing RFCs could focus on pervasive
monitoring, but could do privacy in sector reviews. General nods.
How to approach existing reviews?
* Most “popular” base protocols that get used in new protocols. Stephen: but what are the base
* Christine: … missed it.
* Ask each AD which are the most important 5. -> Stephen will do that.
* Scott and Avri will talk to Christian about more on DHCP.
* Joe Hall and Aruna will do reviews for _something_.
* Scott volunteers for IntArea.
* Scott: URI use always needs careful scrutiny.
* Linus: use Tor as a resource? Can’t block it. … missed it.
* How to build up a list of willing privacy experts, so reviewers can bring them in for help?
* Robin: waiting for it to creep up the stack.
* Karen: general volunteer.
* Steve Kent: avian carriers.
* Say so when you start a review.
* Stephen: have deadlines, mid-May something should be sent as reviews.
* Allison: SDP, RTCP, Radius, Diameter ... all need reviews.
* Avri will keep track of it all on the wiki.
ietf-privacy mailing list
ietf-privacy <at> ietf.org