There was a decision to use the ietf-privacy email list for the PM
review work work instead of the perpass list.
This was sent to ietf-privacy list and then forwarded to perpass, but we
should probably try to limit discussion to the ietf-privacy list if at
all possible.
avri
-------- Original Message --------
Subject: [ietf-privacy] Draft report on IETF89 PM review lunch meeting
report
Date: Wed, 12 Mar 2014 06:19:51 -0400
From: Avri Doria <[email protected]>
To: [email protected]
Draft Meeting report.
A set of notes created by Scott Brim (thanks!) can be found at:
https://docs.google.com/document/d/1GwD5m09p42fS3OWucYwPZ0lWcVN8Y_HIN0yp2BzYYYI/edit?usp=sharing
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
track RFCs
- 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
* http://huitema.net/papers/draft-huitema-perpass-dhcp-identifiers
* http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy
* https://datatracker.ietf.org/doc/draft-seitz-ace-design-considerations/
* Some STRINT contributions
* Specific RFCs (or drafts)
* http://tools.ietf.org/html/rfc6740 - ILNP architecture
* http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn
* http://tools.ietf.org/html/draft-allen-dispatch-imei-urn-as-instanceid
* http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid
* http://tools.ietf.org/html/rfc6740
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 significant insecurities.
* 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.
Reviews:
* 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 protocols?
* 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
