Horne, Rob | 24 Mar 13:31 2014

Re: [perpass] Wiki for managing PPM reviews of existing RFCs

Hi, I’m interested in reviewing RFCs so could someone tell me – or point me in the direction of – what the goals are, how to conduct a review and what exactly are we looking for?








From: ietf-privacy [mailto:ietf-privacy-bounces <at> ietf.org] On Behalf Of Scott Brim
Sent: 24 March 2014 12:23
To: yaojk
Cc: ietf-privacy <at> ietf.org; perpass
Subject: Re: [ietf-privacy] [perpass] Wiki for managing PPM reviews of existing RFCs


On Mar 23, 2014 10:49 PM, "Jiankang Yao" <yaojk <at> cnnic.cn> wrote:
> since there are thousands of RFCs, it is better that they can be reviewd by category.
> for example, based on the following category:
> http://www.faqs.org/rfcs/np.html
> Jiankang Yao

We want to make sure the essential RFCs are reviewed, and categories are a good way to organize that if you know what categories to use. We don't have enough experience yet to know what good categories would be -- we don't know how many reviewers we will have our their interest areas. To start with let's just get everyone doing reviews. We can organize them later, once we get over a hundred.

Thanks... Scott

ietf-privacy mailing list
ietf-privacy <at> ietf.org
Scott Brim | 22 Mar 22:21 2014

Wiki for managing PPM reviews of existing RFCs

(I'm sending to both perpass and ietf-privacy for this announcement,
but follow-up should be only to ietf-privacy)

Greetings. At the London IETF we had a Monday lunch meeting to talk
about doing systematic reviews of existing RFCs. We finally have a
wiki page for tracking that activity. It is at

We are using the Trac ticket system. If you have used tickets for
working group issues, it's essentially the same but with a few
different parameters. There are instructions on how to fill out a
ticket on the web page.

 If you were at the Monday lunch and announced an intention to working
on a particular set of RFCs, now there's a home for your reviews. If
you couldn't commit to doing reviews but want to do some, here is your
chance! (If you don't have a login on the wiki, it's easy to
register.) In both cases, please add a ticket when you _start_ your
review -- don't wait until you finish, people will want to know all
about it from the start.


Scott and Avri
Stephane Bortzmeyer | 20 Mar 15:49 2014

[ietf-secretariat <at> ietf.org: New Non-WG Mailing List: dns-privacy]

A new "official" effort in privacy at IETF. DNS privacy discussions
went out of the DNSOP working group, to this new mailing list.
From: IETF Secretariat <ietf-secretariat <at> ietf.org>
Subject: New Non-WG Mailing List: dns-privacy
Date: 2014-03-17 18:10:46 GMT
A new IETF non-working group email list has been created.

List address: dns-privacy <at> ietf.org
Archive: http://www.ietf.org/mail-archive/web/dns-privacy/
To subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy

Purpose: This list is for the discussion of the problem statement surrounding the addition of privacy to
the DNS protocol.

For additional information, please contact the list administrators.
ietf-privacy mailing list
ietf-privacy <at> ietf.org
Christian Huitema | 16 Mar 07:46 2014

FW: New Version Notification for draft-huitema-perpass-dhcp-identifiers-00.txt

For what it is worth, the draft about DHCP, identifiers and privacy is now published on the IETF servers.

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Wednesday, March 12, 2014 10:40 PM
To: Christian Huitema; Christian Huitema
Subject: New Version Notification for draft-huitema-perpass-dhcp-identifiers-00.txt

A new version of I-D, draft-huitema-perpass-dhcp-identifiers-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-perpass-dhcp-identifiers
Revision:	00
Title:		Unique Identifiers in DHCP options enable device tracking
Document date:	2014-03-13
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-huitema-perpass-dhcp-identifiers-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-perpass-dhcp-identifiers/
Htmlized:       http://tools.ietf.org/html/draft-huitema-perpass-dhcp-identifiers-00

   Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  This document reviews these options and proposes
   solutions for better management.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
Avri Doria | 12 Mar 11:19 2014

Draft report on IETF89 PM review lunch meeting report

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 
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. 

* 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
Fred Baker (fred | 26 Feb 09:59 2014

In case you haven't seen it yet

ietf-privacy mailing list
ietf-privacy <at> ietf.org
S Moonesamy | 18 Dec 21:04 2013

Re: Article, toward a definition of privacy (or perhaps not).

Hi Nat,
At 06:57 18-12-2013, Nat Sakimura wrote:
>Perhaps you did not read my blog post.

I read the blog post.  The image in the post highlights the different angles.

>Warren and Brandeis quoted "to be let alone" from Cooley. It goes this way:
>Recent inventions and business methods call attention to the next 
>step which must be taken for the protection of the person, and for 
>securing to the individual what Judge Cooley calls the right "to be let alone"

Yes.  There is a newspaper article that led to the above.

>In turn, Cooley used the phrase this way:
>Personal immunity. The right to one's person may be said to be a 
>right of complete immunity: to be let alone.

The paragraph containing the sentence is about Torts.

>Therefore, what was meant by W&B is indeed is the right of complete 
>immunity. Somehow, American lawyers started to take them narrower 
>than what is apparently stated in the paper. However, going back to 
>the original, it is pretty good actually.


>As to the "right" is concerned, I am not sure if it is "guaranteed 
>by law" all the time. It is not always that clear. In this 
>particular case, what belong to the person, and what to the 
>community and the public is not always clearly delineated.

The word "guaranteed" (which I used) is not the correct term.  What 
you wrote above sums it up.

>As a standard body which sets standards, which are not regulations 
>(in the sense of ISO Guiide 2), there is no value if we go below the 
>regulations as it is going to be illegal then. It has to set a 
>higher standard and thus the amount that we have to cover is larger 
>than those regulations covers.

I look at it this way; it has to be something IETF participants will 
agree to.  That's the difficult part. :-)

S. Moonesamy 
S Moonesamy | 18 Dec 14:17 2013

Re: Article, toward a definition of privacy (or perhaps not).

Hi Nat,
At 03:58 18-12-2013, Nat Sakimura wrote:
>Agree that people use the word privacy without clearly defining or 
>understanding what it is. In this sense, we should avoid dictionary 
>term - layman's term entirely. When we need to discuss properly, we 
>need to define it first and then use it.
>In this sense, as I wrote in one of my blog post [1], the original 
>Warren and Brandeis [2] definition seems to be pretty good, though 
>it is one of the most misunderstood definition, IMHO.
>They said privacy is right to be let alone. This "let alone" is the 
>specific words from Cooley [3] but people seem to have taken it as 
>dictionary word and hence much confusion. If you read it, it means: 
>"right of complete personal immunity".
>I suppose, to avoid confusion, it probably is better to use the 
>definition portion of it instead of the defined word in the usual conversation.

There has been some discussion on other IETF mailing lists about the 
definition of the word "privacy".  Warren and Brandeis are often 
cited in a U.S context.  The "right of personal immunity" is broader 
than privacy.

Within an IETF context it might be a problem if the "right to be let 
alone" is used.  In my opinion a right is guaranteed by law and that 
doesn't fit in with what the IETF does.

S. Moonesamy 
Dean Willis | 18 Dec 01:00 2013

Article, toward a definition of privacy (or perhaps not).



An exceprt:

"I'd add one more item to Solove's list of definitions: when people speak of privacy, often what they're
really concerned about is not privacy at all, but very concrete kinds of economic and physical harm: job
loss, theft, injury, imprisonment, and even death. That is: when people speak of privacy they're often
speaking -- albeit indirectly -- about power, and its uses and abuses.”

"It's one thing to know, in the abstract, that anyone walking by your house can see into your kitchen window,
but it's another thing altogether to look out the kitchen window and discover someone staring fixedly at
you. It's one thing to know that the soccer mom sitting one table over at Starbucks can probably make out the
words on your laptop screen; it's another thing altogether to know that "the government" can do the same thing.”

"The man staring fixedly through our kitchen window bothers us not because we think he might discover us
doing something "secret," but because he has violated norms of socially acceptable behavior in a way that
makes him unpredictable: if he's willing to violate norms against staring, what other norms might he also
violate? Will he become a stalker, a blackmailer, a burglar, a rapist, a murderer?"

"Privacy is a red herring in the debate about NSA surveillance (and many other kinds of covert activities).
If we want meaningful reform, we need to set aside the rhetoric of privacy, and focus instead on creating
genuine safeguards against the abuse of government power."

Stephane Bortzmeyer | 19 Nov 10:33 2013

"Opportunistic encryption" and a need for a definition

[Long quiet time on this list, time to resume discussions.]

In draft-cooper-ietf-privacy-requirements-01, I find:

   "Opportunistic encryption" is defined as encryption without any pre-
   arrangement specific to the pair of systems involved (e.g., by using
   a Diffie-Hellman exchange).  See [RFC4322].

I find this definition confusing (specially the reference to DH)
because it does not match the rest of the text which says:

   Where both opportunistic and one-sided or mutually
   authenticated encryption are specified, protocols MUST also protect
   against downgrade attacks so that scenarios where authentication is
   required cannot easily be manipulated into using opportunistic
   encryption which will often be subject to man-in-the-middle

The second paragraph seems to use OE as meaning "encryption without
authentication" (which is indeed vulnerable to man-in-the-middle
attacks). This is also how "opportunistic" is used in RFC 5386.

The first paragraph (and RFC 4322) have a different meaning, OE being
"encryption without peer-specific setup" (and therefore being
authenticated, and not vulnerable to man-in-the-middle attacks).

The discussions in Vancouver were very confused as well. Everyone was
talking about OE but with a different definition in mind. I strongly
suggest that we need either to have one definition and to stick with
it (the current draft is self-contradictory). Or to give in and to
stop using the term OE, poorly defined, and too loaded.

Do not that Wikipedia has a third definition of OE (encryption with a
fallback to an unencrypted
mode) http://en.wikipedia.org/wiki/Opportunistic_encryption
Eliot Lear | 24 Sep 12:41 2013



I've done a bit of back and forth with Stephen elsewhere, and I have a few comments about the draft.

Opportunistic encryption really means different things to different people.  It is actually NOT well defined in RFC 4322, and in that case they're referring to encryption between L3 endpoints where you retrieve keying information from the DNS using the KEY record and DNSSEC.  That is not what is implied by the following paragraph:

   While existing principles call for strong security, it is important
   to note that strong security only in cases where the other party can
   be authenticated does not by itself solve all privacy problems.  To
   guard against dangers of large-scale privacy attacks, some protection
   is needed also for other situations.  As a consequence, at minimum,
   opportunistic encryption needs to be well-defined for almost all new
   IETF standards track protocols.  In most cases it will be better to
   (also) specify how to do mutually authenticated encryption.
   Encryption provides one aspect of privacy protection, namely

That is to say, the concepts of opportunistic and authenticated or unauthenticated encryption are orthogonal. It is worth noting that by the use of the term, one could reasonably argue that TLS is opportunistic encryption because the encryption is not prearranged in advance by two parties.  If that is the bare minimum, then IMHO that is largely what is intended by RFC 3365 already.  I more than suspect that's not what the intent of this draft is.

And so this raises three questions:
  1. First, what is really meant by opportunistic encryption in this case?
  2. What are the appropriate approaches for opportunistic encryption? and
  3. What are the best practices  (i.e., "Do"s and "Don'ts"; after all, this is meant to be a BCP)?

Also, some protocols have evolved to allow for sharing of private information, for better and worse.  There are tradeoffs associated with privacy versus security (such as the benefit of a transparent malware scanner).  These tradeoffs should be discussed in security considerations.


ietf-privacy mailing list
ietf-privacy <at> ietf.org