Subject: Re: [hrpc] Examining existing Venue Selection criteria

From: Niels ten Oever <[email-masked]>
Date: Thu, 2 Jun 2016 14:16:14 +0200

Hi all,

On 05/27/2016 04:04 PM, Scott Craig wrote:
> H Niels,
> 
> A couple of thoughts on the venue selection process
> 
> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3 
> <https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3><https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3>
> 
> 
> 
> 
> *1. Can it be established whether or not the IETF considers Human Rights
> to be 'political criteria'. *
> 
> 
> Political considerations: The IETF does not make political statements.
> We do not decide who is or is not a country, and we do not choose or not
> choose venues based on political criteria.
> 

The us of the word 'political' here is quite problematic imo. It is very
hard to delineate what is political and what is not, and as Laura
DeNardis  argues in 'Protocol Politics' (p.6): 'Protocols are
political'. So both saying that the IETF does not make political
statements is I think not consistent with for instance RFC3271, RFC1958,
RFC7258, etc, and 'and we do not choose or not choose venues based on
political criteria' is I think incorrect if you look at the 'principles
of inclusiveness' mentioned further down in the same document.

> *2. Can it be established whether or not the IETF formally considered
> its 'principal of inclusiveness' in previous venue selections.
> *Inclusiveness:
> 
>       We *_would like_* to facilitate the onsite or remote participation of
>       anyone who wants to be involved.  Every country has limits on who
>       it will permit within its borders.  *_This principle of inclusiveness militates against the selection of
> venues within countries that impose visa regulations and/or laws that
> effectively exclude people on the basis of race, religion, gender,
> sexual orientation, or national origin,_* and to a lesser extent,
>       _reduces the likelihood_ of selecting countries that use such
>       attributes to make entry difficult.
> 

I like the language as suggested by Robert in line with text on UN
events (http://mirror.unhabitat.org/categories.asp?catid=831).

I do think though that this could help us with the ongoing discussion
instead of being a replacement of the previous text:

We *would like* to facilitate the onsite or remote participation of
anyone inclusive and free from any form of discrimination, based on
gender, age, health status, disability, income, nationality, ethnicity,
migratory condition, or political, religious or sexual orientation ,
where all participants are granted equal opportunities to contribute to
the IETF standards making process.

Happy to further discuss.

Best,

Niels

> Scott
> 
> 
> On Fri, May 27, 2016 at 2:00 PM, Niels ten Oever <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
> 
>     Let's not come to rapid conclusions. Let's first see what different
>     criteria there are (having meetings in different parts of the world also
>     being one as clearly outlined here:
>     https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02
>     ) and when we have different criteria that are important we can
>     prioritize them and develop a method of weighing them.
> 
>     And let's first keep this to the IETF, and when we work it out here, we
>     can think of other fora.
> 
>     Best,
> 
>     Niels
> 
> 
> 
>     Niels ten Oever
>     Head of Digital
> 
>     Article 19
>     www.article19.org <http://www.article19.org>
> 
>     PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                        678B 08B5 A0F2 636D 68E9
> 
>     On 05/27/2016 02:56 PM, Robert Guerra wrote:
>     > Is hosting a meeting a meeting in Singapore , how about the UAE?
>     >
>     > ICANN 60 will be held in Abu Dhabi . Does this group and others wish
>     > to raise any human rights concerns in regards to having the meeting
>     > held in the UAE
>     >
>     > Regards
>     >
>     > Robert
>     >
>     >
>     > Sent from my iPhone
>     >
>     >> On May 27, 2016, at 7:56 AM, Niels ten Oever <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >> Thanks for this.
>     >>
>     >> With a lot of interest I have been following the discussion at
>     >> [email-masked] <mailto:[email-masked]> about the IETF100 location,
>     for which the IAOC selected
>     >> Singapore, and which was strongly questioned by Ted Hardie at in
>     Buenos
>     >> Aires at the plenary.
>     >>
>     >> I do not want to replicate that discussion here, but at several
>     points
>     >> it was brought up that the human rights situation in a specific
>     country
>     >> might be reason to not have a meeting there.
>     >>
>     >> I think this is something that deserves discussion here, and if we
>     >> manage to come to a approach, we could suggest integration of that in
>     >> this draft:
>     >>
>     https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02
>     >>
>     >> Curious to hear what you all think.
>     >>
>     >> Best,
>     >>
>     >> Niels
>     >>
>     >> Niels ten Oever
>     >> Head of Digital
>     >>
>     >> Article 19
>     >> www.article19.org <http://www.article19.org>
>     >>
>     >> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>     >>                   678B 08B5 A0F2 636D 68E9
>     >>
>     >>> On 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote:
>     >>> Beautiful rant against IETF. Encryption and LGBT rights, same
>     >>> struggle?
>     >>>
>     >>>
>     http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/
>     >>>
>     >>> _______________________________________________
>     >>> hrpc mailing list
>     >>> [email-masked] <mailto:[email-masked]>
>     >>> https://www.irtf.org/mailman/listinfo/hrpc
>     >>
>     >> _______________________________________________
>     >> hrpc mailing list
>     >> [email-masked] <mailto:[email-masked]>
>     >> https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
>     _______________________________________________
>     hrpc mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> 
> 
> -- 
> 
> *Scott Craig* | Ford-Mozilla Fellow
> Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
> *E:* [email-masked] <http://cdt.org/> | *D:* 1.202.407.8887
> <tel:202.407.8887> | **@scottdavidcraig
> 
> */
> /*
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 13:40:03 +0100

On 02/06/16 13:16, Niels ten Oever wrote:
>  So both saying that the IETF does not make political
> RFC7258, etc,

FWIW, I disagree, though this is clearly a thing on which
reasonable folks take different positions.

From my POV, RFC7258 makes technical statements and is one.

RFC7258 is of course also relevant to areas of policy that
are rightly called political, but the text itself is not
well described as a political statement - it's a technical
statement with policy consequences.

To try use an analogy to explain - a document describing
weather patterns ought not be considered political, but
deciding how to deal with global climate change clearly is.
Some IETF documents are like the former. And yes, people
doing politics will refer to and use those according to
their political inclinations but that does not make a
set of barometer readings a political statement. Printing
those out and nailing them to a door however, might be
one.

S.

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 2 Jun 2016 14:44:58 +0200

> those out and nailing them to a door however, might be
Hi Stephen,

I can draft several responses to this, but to ensure I understand you
correctly, do you also think that RFC3271 and RFC1958 don't make
political statements?

Best,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 13:52:23 +0100

> correctly, do you also think that RFC3271 and RFC1958 don't make

I'd have to re-read 'em to say really but on 1st glance no.
Seems fairly clear for 1958, for 3271 that seems like a
bit of aspirational writing. While I guess one might consider
3271 more political than other things, I'm also fine that
there may be exceptions in the nearly 8000 RFCs issued but
I do not accept that one can go from there to saying that
the IETF makes political statements. (And those are old
too.)

S.

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 2 Jun 2016 15:01:16 +0200

> the IETF makes political statements. (And those are old

Thanks Stephen,

Unfortunately I have to disagree. I think the process in the IETF and
statements that are made in RFCs are highly political. Because, and let
me quote Laura DeNardis here:

[Protocols] control the glbal flow of information and make decisions
that influence access to knowledge, civil liberties online, innovation
policy, national economic competetiveness, national security, and which
technology companies will succeed.

So this goes far beyond aspirational quotes imho.

Best,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 14:07:42 +0100

On 02/06/16 14:01, Niels ten Oever wrote:
> Unfortunately I have to disagree. 

That's fine.

> I think the process in the IETF and

Yes, the process is political because it involves humans,
sure. That does not mean the output of the process is
well described as political statements. University politics
is notoriously political, but most academic publication is
not.

> statements that are made in RFCs are highly political.

Fully disagree. Almost all RFC text is dry old technical crap.
The little that is not, is almost-all technical with policy
implications like 7258. "Highly political" is just not in
any universe an accurate description of the RFC series.

> Because, and let

I don't agree with that either, but there's a lot of subtlty
as to who controls what when real networks are considered.
The idea that some RFC describing a DHCP option is therefore
definitely political is, to me, nonsense.

Cheers,
S.

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 09:34:13 -0400

On Jun 2, 2016, at 9:07 AM, Stephen Farrell <[email-masked]> wrote:
> implications like 7258.

Hmm,

RFC7258 is predominantly technical criteria for protocols, but does
take a specific stance regarding tradeoffs of various “public policy”/
civic norms and standards - i.e. the conclusion that the inability to
distinguish “legitimate” from "non-legitimate" pervasive monitoring
(PM) actors requires that all PM be considered considered an
“attack” and mitigated against during protocol design.

This taking of a particular stance regarding appropriate tradeoffs
of civic norms and standards would traditionally called 'taking a
political position’, even if doing so via technical criteria statements.

Note - there is not anything inherently wrong with enshrining specific
tradeoffs in civic values in protocol design (and in fact, it may not be
humanly possible to design reasonable protocols which otherwise
attempt to accommodate a diverse range of value tradeoffs), but the
IETF should probably take extra care to utilize a very well publicized
and overly inclusive process when in undertakes such activities.

/John

Disclaimer: my views alone (and hopefully carried by protocols that
do not care about my particular politics… ;-)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 14:58:16 +0100

Hiya,

Just on this example...

> “attack” and mitigated against during protocol design.

Frankly, I don't see what other conclusion could be reached.
One could I guess question the premise that those things are
not distinguishable, but a) I don't think that's really
credible, and b) I don't recall anyone actually making a
real case that distinction is technically feasible (but there
was a *lot* of discussion... see below;-)

So no I don't accept that that conclusion is political in
itself. I do accept that some people consider it so, but
you'll have to explain to me where the politics enters in
between the premise and the conclusion.

> and overly inclusive process when in undertakes such activities.

I fully agree that extra care needs to be taken with things like
7258. That did happen though - we had a tech plenary on the topic
in Vancouver and setup a mailing list and had about 1000 mails on
[email-masked] during an extended IETF LC that lasted a couple of
months iirc. There was a similar kind of consideration for 2804
as well, so overall I think the IETF handles these kinds of things
fairly well when they come up.

Cheers,
S.

> [email-masked]

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 10:13:56 -0400

> was a *lot* of discussion... see below;-)

Stephen - Did any of the governments that participated in the discussion
suggest that pervasive monitoring served an important societal purpose,
and that the IETF consider whether there were any technical options for
allowing it under “legitimate” conditions?  Where is the discussion of the
societal implications documented?

> between the premise and the conclusion.

I won’t debate the merits of the term “political”, but it is clear that there was
specific position on a matter of public policy taken within RFC7258.  You
may feel that there was no other reasonable technical position, but that’s
immaterial to whether the IETF document enshrines certain public policy
views.

> fairly well when they come up.

I apparently was misunderstood - by “inclusive", I meant with specific
outreach to other potentially affected stakeholders who might otherwise
be unaware of the public policy discussion going on at the IETF.   (For
example, each of the RIRs has government working groups which help
governments be aware of, and engage with, the various ongoing registry
policy discussions in each region.)   Did the IETF reach out to any of
various government associations (or perhaps to the Government
Advisory Committee in ICANN) to appraise of them of the activity?

Thanks,
/John

Disclaimer: My views alone - feel free use, abuse, or discard as desired.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jun 2016 16:14:24 +0200

On Thu, Jun 02, 2016 at 02:07:42PM +0100,
 Stephen Farrell <[email-masked]> wrote 

> definitely political is, to me, nonsense.

Bad example, just after the publication of RCF 7844 :-)

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 10:29:34 -0400

> Bad example, just after the publication of RCF 7844 :-)

Interestingly enough, I don’t see RFC 7844 as taking a public policy position
(at least as far as I can tell), as all it is doing is providing option that would allow
DHCP clients an anonymous profile.  This doesn’t remove any choices or force
any outcome, but simply provides an options for those who desire such.  Users
who value such can use it, governments who feel it is not appropriate can pass
laws forbidden its use, etc.  

If the IETF were to take the stance that use of the anonymous profile were required,
then that certainly would be taking a particular public policy stance, since there is
no meaningful way to work around such a standards result.  Given the popularity 
of the Internet protocol suite (with near ubiquitous acceptance globally), the IETF 
needs to take particular care when it enshrines tradeoffs on public policy matters 
via mandatory protocol specification.  

/John

Disclaimer: My views alone - even my keyboard claims no association w/same.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jun 2016 16:37:05 +0200

On Thu, Jun 02, 2016 at 10:29:34AM -0400,
 John Curran <[email-masked]> wrote 
 a message of 41 lines which said:

> Interestingly enough, I don’t see RFC 7844 as taking a public policy
> position (at least as far as I can tell), as all it is doing is
> providing option that would allow DHCP clients an anonymous profile.
> This doesn’t remove any choices or force any outcome, but simply
> provides an options for those who desire such.

Actually, this was the state before RFC 7844 which was a policy
position: because there was no standard way to have "anonymity" with
DHCP, people were *forced* to reveal things about themselves (there
were even some data-leaking options which were mandatory, see RFC
4361, section 6.1, which made option "client identifier" compulsory).

So, it is a nice example of how code embodies political positions.

See also RFC 7819 and RFC 7824 for an analysis of the problem.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 16:12:28 +0100

Hiya,

> Stephen - Did any of the governments that participated in the discussion

Well I've no idea which IETF participants do or do not reflect
what government positions. As you know, that's not how the IETF
works. (If you want to change that, that's a different discussion.)

> allowing it under “legitimate” conditions?  

But that is not the issue raised. RFC7258 is silent about
that iirc. The IETF neither "allows" nor "disallows" PM.

The issue raised here is whether or not there is some political
element to the technical consequences of the indistinguishability
between different motives for PM. I still don't see that
there is.

> Where is the discussion of the

We don't do that no. But was that possibly a rhetorical
question like this one? :-)

If you want to propose that the IETF ought formally do such
things, then feel free... but I suspect you already know how
major a change that'd represent and how difficult it would be
to get such a change. (And as it happens, I'm fairly sure I'd
personally prefer how the IETF is setup today to the kind of
thing that I think would be necessary for such formal
consultation with governments or companies to be part of IETF
process.)

S.

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 11:18:14 -0400

> 4361, section 6.1, which made option "client identifier" compulsory).

Acknowledge - prior state enshrined public policy positions; post-RFC7844
allows voluntarily adoption.

> So, it is a nice example of how code embodies political positions.

Agreed (I think) - it is a good example of how some standards/code _can_ 
embodies specific public policy positions, but in the post-RFC state how it is 
also possible (likely?)  that standards/code doesn’t need to do so.   I concur 
with Stephen that the vast majority of IETF specifications are technical in 
nature (with de minimis public policy implications), but believe it evident 
that is not always the case.

/John

Disclaimer: my views alone - no warranty expressed or implied, other than 
potentially seed material for random() functions.

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 11:42:22 -0400

On Jun 2, 2016, at 11:12 AM, Stephen Farrell <[email-masked]> wrote:
> ...

Sorry, that’s a difference without a distinction: the IETF categorized _all_ PM
as an attack, and set the requirement for protocol developers to work towards
mitigation of same.  The reasoning behind such a position doesn’t alter the
fact that the position embeds a certain public policy position - specifically,
that the mitigation is necessary despite implications for lawful PM.

I actually think that RFC7258 outcome is the correct one, but to take such a
position without clearly documenting the fact that technical accommodation
of “legitimate” PM wasn’t feasible (as well as the actual reasoning why the
public policy tradeoff is reasonable) doesn’t make for an easily accessible
record of the decision process.

> between different motives for PM. I still don't see that

Acknowledged that you do not, and I perhaps am insufficiently clear in my
explanation to be much help in this regard.

> to get such a change.

It’s probably unnecessary (unless the IETF intends to mandate additional
public policy positions via its standards activities.)  That is clearly germane
to the discussion of HRPC work direction and modes of operation.

> (And as it happens, I'm fairly sure I'd

You state “formal consultation”, whereas I was very careful to use the term
“outreach”…  there is a huge difference between the two - the former involves
seeking a specific position from another body, the latter (outreach) simply
means making an effort to notify another party that you are now undertaking
work in given area, and that they can participate (or not) in the IETF’s work
as they choose.

/John

Disclaimer: my views alone - made from 100% recycled electrons.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 16:47:10 +0100

> work in given area, and that they can participate (or not) in the IETF’s work

That's fair.

In the case in question, there was sufficient publicity
about it that I don't think there was a real problem with
that. (There is an ongoing issue about how entities like
governments can usefully take part as IETF participants
but that's yet another issue.)

Cheers,
S.

---

From: Jeroen van der Ham <[email-masked]>
Date: Thu, 2 Jun 2016 19:50:02 +0200

Hi,

> On 02 Jun 2016, at 15:01, Niels ten Oever <[email-masked]> wrote:

My 2 cents:

The IETF WGs take decisions based on technical arguments. At some point, some internal politics may be involved, but the process in the IETF is designed such that this is minimised as much as possible. How operators and administrators deal with the outcome of the IETF process is not up to the IETF.

Jeroen.

---

From: avri doria <[email-masked]>
Date: Thu, 2 Jun 2016 15:31:12 -0400

Hi,

This has been an interesting discussion.

But I find myself wondering what it has to do with human rights protocol
considerations and whether this is the right list for those discussions.

Thanks
avri

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Jun 2016 21:20:59 +0000

If you're hoping to get this into the mtgvenue document, may I suggest you move the conversation to the [email-masked] list where that discussion is happening?

> On May 27, 2016, at 7:29 AM, Robert Guerra <[email-masked]> wrote:
> 
> Scott,
> 
> If it’s not too late, might I propose a suggested revision to the paragraph so that it is consistent with language terms used in  UN processes, such as the ongoing Habitat III negotiations
> 
> http://mirror.unhabitat.org/categories.asp?catid=831
> 
> Below is a suggested revision of the paragraph.
> 
> 
> 
> We *would like* to facilitate the onsite or remote participation of inclusive and free from any form of discrimination, based on gender, age, health status, disability, income, nationality, ethnicity, migratory condition, or political, religious or sexual orientation , where all inhabitants, whether permanent or transitional, are granted equal rights and opportunities, according to the United Nations Charter principles and the relevant provisions of international law.
> 
> 
> This paragraph might be missing certain aspects of the original paragraph. Do add them back in :)
> 
> regards
> 
> Robert
> 
> --
> Robert Guerra
> Twitter: twitter.com/netfreedom
> Email: [email-masked]
> PGP Keys : https://keybase.io/rguerra
> 
> On 27 May 2016, at 10:04, Scott Craig wrote:
> 
>> H Niels,
>> 
>> <https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3>
>> <https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3>
>> 
>> 
>> 
>> *1. Can it be established whether or not the IETF considers Human
>> Rights to be 'political criteria'. *
>> 
>> 
>> Political considerations:
>>      The IETF does not make political statements.  We do not decide who
>>      is or is not a country, and we do not choose or not choose venues
>>      based on political criteria.
>> 
>> 
>> its 'principal of inclusiveness' in previous venue selections.*
>> Inclusiveness:
>> 
>>      it will permit within its borders.  *This principle of
>>      inclusiveness militates against the selection of venues within
>>      countries that impose visa regulations and/or laws that
>>      sexual orientation, or national origin,* and to a lesser extent,
>>      *reduces the likelihood* of selecting countries that use such
>> On Fri, May 27, 2016 at 2:00 PM, Niels ten Oever <[email-masked]>
>> wrote:
>> 
>>> Hi Robert,
>>> 
>>> www.article19.org
>>>>> On May 27, 2016, at 7:56 AM, Niels ten Oever <[email-masked]>
>>> wrote:
>>>>> 
>>>>> Thanks for this.
>>>>> 
>>>>> [email-masked] about the IETF100 location, for which the IAOC selected
>>>>> Singapore, and which was strongly questioned by Ted Hardie at in Buenos
>>>>> Aires at the plenary.
>>>>> 
>>>>> I do not want to replicate that discussion here, but at several points
>>>>> it was brought up that the human rights situation in a specific country
>>>>> www.article19.org
>> *E:* [email-masked] | *D:* 1.202.407.8887 | @scottdavidcraig
>

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 19:45:32 -0400

> considerations and whether this is the right list for those discussions.

Avri -

I believe that Niels raised a valid question about whether "the IETF does not
make political statements” is consistent with RFC7258 (et al)

Depending on the resolution of that question, one can expect very different
language to appear in draft-tenoever-hrpc-research…  In fact, one can easily
imagine different outcomes of the HRPC work depending on the answer.

/John

Disclaimer: my views alone. note - past performance is not a reliable indicator
of future results.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Jun 2016 23:55:21 +0000

> On Jun 2, 2016, at 4:45 PM, John Curran <[email-masked]> wrote:
> 

hrpc being, of course, an IRTF RG, not an IETF WG.

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 20:06:12 -0400

On Jun 2, 2016, at 7:45 PM, John Curran <[email-masked]> wrote:
> ….

To elaborate for clarity, consider the following text in the "Charter of Human Rights
and Principles for the Internet” (produced by "Internet Rights and Principles Dynamic
Coalition” (available here: <http://internetrightsandprinciples.org/site/wp-content/uploads/2015/01/IRPC_english_4thedition.pdf <http://internetrightsandprinciples.org/site/wp-content/uploads/2015/01/IRPC_english_4thedition.pdf>>)

> "As enshrined in Article 3 of the UDHR: "everyone has the right to life, liberty and security of person".
> All security measures must be consistent with international human rights law and standards. This means that security measures will be illegal where they restrict another human right (for example the right to privacy or the right to freedom of expression) except for in exceptional circumstances. All restrictions must be precise and narrowly defined. All restrictions must be the minimum necessary to meet a genuine need which is recognized as legal under International law, and proportionate to that need.
> 
i.e. application of the principles in cases where there are overlapping requirements
requires consideration of the appropriate circumstances which qualify as exceptional
and determination of the minimum impact strictly necessary to accomplish the genuine
and legal need…   by definition, the act of considering the application of these rights
in total requires what is commonly referred to "public policy” determinations.

It’s fairly easy for the IETF to consider how protection of a specific human right might
impact protocol design, but it would be very challenging to give balanced consideration
to protocol technical requirements that protect human rights overall unless it asserts
some particular set of public policy tradeoffs regarding the appropriate way these rights
are to be balanced on the Internet. There’s nothing wrong with the IETF doing so, so
long as it is recognized as public policy position taking and not covered with a veneer
“setting technical requirements."

/John

Disclaimer: my views alone - those reading may experience different results.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 3 Jun 2016 00:11:49 +0000

> make political statements” is consistent with RFC7258 (et al)

Speaking for myself alone.

I think an important consideration in that is the definition of an "attack", noted in the third and fourth paragraphs of section 1. As noted there,

   The term "attack" is used here in a technical sense that differs
   somewhat from common English usage.  In common English usage, an
   attack is an aggressive action perpetrated by an opponent, intended
   to enforce the opponent's will on the attacked party.  The term is
   used here to refer to behavior that subverts the intent of
   communicating parties without the agreement of those parties.  An
   attack may change the content of the communication, record the
   content or external characteristics of the communication, or through
   correlation with other communication events, reveal information the
   parties did not intend to be revealed.  It may also have other
   effects that similarly subvert the intent of a communicator.
   [RFC4949] contains a more complete definition for the term "attack".
   We also use the term in the singular here, even though PM in reality
   may consist of a multifaceted set of coordinated attacks.

   In particular, the term "attack", used technically, implies nothing
   about the motivation of the actor mounting the attack.  The
   motivation for PM can range from non-targeted nation-state
   surveillance, to legal but privacy-unfriendly purposes by commercial
   enterprises, to illegal actions by criminals.

No, that's not a political statement. It is a technically accurate statement about pervasive monitoring. One variation on Pervasive Monitoring is carried out by web sites that measure their user's behavior with a view to advertising to them; the users increasingly respond by blocking adware and tracking attempts. Another form, had Apple (in this case) succumbed to subpoenas, is the issue of "storing one's data in the cloud". If the cloud can now be coerced to turn that data over to a third party, whether law enforcement or organized crime, or hacked to deliver the contents to some other country, the service itself becomes a disservice, and - well, how many people trusted the Office of Personnel Management with classified security records related to personnel, and how many of them do now? And oh yes, let's discuss NSA and CBHQ. Several articles assert that people posting on Facebook and other sites have become measurably more "conservative in what they send".

Pervasive monitoring is an attack in the technical sense that it subverts the user's intent regarding their data, regardless of who the user is, and regardless of who is monitoring them.

That has nothing to do with the mtgvenue document, which is about venue selection and the pressures sometimes placed on IETF leadership to support the politics of someone in the country being visited, or to comment on laws in that country, whether enforced or otherwise.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Jun 2016 10:39:18 +1000

This is a good discussion to have.

My .02 -

> statement with policy consequences.

The political statement it makes is that the ability of two parties to communicate without observation ("privacy") is more important than anyone else's ability to monitor that communication (it is an "attack"), as a property of the Internet. To many people and in many jurisdictions, that is an unavoidably a political assertion. 

Note that I don't think that RFC7258 is bad, nor is making such a statement as the IETF. If we were to avoid doing so, we'd be hamstrung; there's very little that we could argue for or against doing in protocols, because someone would object -- whether that be governments, operators, vendors or users. The IETF works because we have a broadly shared idea of what "fit for purpose" means for the Internet, and Pervasive Monitoring didn't fit into that.

What's important is that we followed our documented, open consensus process in publishing that statement, and that we made sure it was relevant to our work. Some people think that RFC was overreaching; others think it didn't go nearly far enough, so it's probably about right.

> Some IETF documents are like the former. 

I think that's a poor metaphor; weather patterns are documenting something that occurs (sometimes naturally, sometimes manmade); the document *describes* the weather patterns, it does not define them. IETF documents (at least good ones) document protocols that are agreed to by implementers during the process of their definition. They have an opinion about how the world should work, even if their authors refuse to admit so.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: John Curran <[email-masked]>
Date: Thu, 2 Jun 2016 20:47:20 -0400

On Jun 2, 2016, at 8:11 PM, Fred Baker (fred) <[email-masked]> wrote:
> No, that's not a political statement. It is a technically accurate statement about pervasive monitoring.

Fred -

The political statement starts two lines further down in the document -

  "The same techniques to achieve PM can be used regardless of motivation.
  Thus, we cannot defend against the most nefarious actors while allowing
  monitoring by other actors no matter how benevolent some might consider
  them to be, since the actions required of the attacker are indistinguishable
  from other attacks.  The motivation for PM is, therefore, not relevant for
  how PM is mitigated in IETF protocols.”

i.e. the characterization of PM as an “attack” is predicated on the fact that
_defense against nefarious actors_ takes precedence over any possible
legal use of PM (even to the point of not bothering to consider if support
of legal PM was technically possible.)

The IETF made a determination that its protocols should mitigate against
“legal” pervasive monitoring, without bothering to even consider if such
activities might be accommodated.  This is actually quite a commendable
position, but involves making a determination of the “right" _public policy_
tradeoff (of privacy and security over support for the any perceived or
potential legal requirements for PM) - i.e. a public policy determination
being made by the IETF for all  Internet users; the political stance then
enables the establishment of technical requirements contained in the
document.

As a thought exercise, consider what the IETF would have produced if it
had took a purely technical approach to the problem - it could have done
a detailed analysis that indicated that is not feasible to somehow provide
for collection of PM data and "exceptional access” to the resulting data
for those who might have valid legal need - ergo, PM cannot be safely
support, will be deemed at attack, and mitigated in protocol design.   We
only got the final result, without any documented analysis of the public
policy implications of the position or technical analysis of why supporting
“legal” PM isn’t reasonable.

/John

Disclaimer: my views alone; as a reminder, email filters are your friend.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 3 Jun 2016 01:12:43 +0000

> On Jun 2, 2016, at 5:47 PM, John Curran <[email-masked]> wrote:
> 
> We

I'll grant you at least some of that. Speaking from personal experience (RFC 3924), though, I think I have already been through the analysis. Lawfully Authorized Electronic Surveillance, aka Lawful Intercept, is an active attack in the sense that a probe of some sort is inserted into the network to monitor the communications of a party that uses it. It is presumably sanctioned by a legal procedure that recognizes that it is what Isaih would call our "strange work". My company addressed the issue because we were in effect required to; our customers were required to have a solution, and we are/were their vendor. In the analysis, the simplest and cheapest thing to do was split them cable and run one end to law enforcement. We were concerned about the issues (which came up in Greece in 2002, and with LAPD at least twice in the mid 1990's) of a party not lawfully authorized to use the capability gaining access to it. Our solution was auditing of the capability; if organized crime leaned on a public official or a back door was activated, we would at least know how and when it happened.

The issue that RFC 7258 responds to is activities claimed to be legal/authorized, but making no sense under a "reasonable man's" interpretation of the Constitution or US Law. One example, finding that Google had what amounts to a split data center, the two halves connected via an undersea cable, and tapping the cable in order to insert a tap *inside* the company. You have followed the media as much or more than I have, so you know what I refer to. An audit trail isn't going to fix an overt miscarriage of jurisprudence such as that. From my perception, if we're dealing with a party that will analyze and overcome any reasonable technical obstacle we set up, technology isn't the solution. Yes, we recommend encryption in any and every case that it makes economic sense. But ultimately someone needs to say "enough!".

RFC 7258 is the IETF's way of saying "enough". You're correct that we didn't go through all of the hoops we do with technology problems, but I actually think we correctly recognized that this was not a technology problem, nor was it solvable by technology. And if that's political, so be it.

But that has nothing to do with venue selection, which is the context of the statement being quoted on hrpc.

---

From: John Curran <[email-masked]>
Date: Fri, 3 Jun 2016 06:17:32 -0400

On Jun 2, 2016, at 9:12 PM, Fred Baker (fred) <[email-masked]> wrote:
>> We only got the final result, without any documented analysis of the public
> ...From my perception, if we're dealing with a party that will analyze and overcome any reasonable technical obstacle we set up, technology isn't the solution. Yes, we recommend encryption in any and every case that it makes economic sense. But ultimately someone needs to say "enough!".
> 
> But that has nothing to do with venue selection, which is the context of the statement being quoted on harp.

The discussion does, however, have everything to do with the work on this list with
respect to <draft-tenoever-hrpc-research>, and how that work is characterized and
explained to others.   There is nothing wrong with the IETF describing that work
as identification of the technical aspects that should be considered in protocols
with respect to a specific subset of human rights, but quite different if the it is
intended as a guide or aid in the comprehensive analysis of whether a given
protocol adequately protects human rights - the latter first requires determination
of the specific set of “appropriate" tradeoffs among the public policy requirements
and it would be best if that aspect of the work were recognized and widely
communicated to interested parties, if the result is to have widespread validity.

There is no reason for the IETF to shy away from difficult public policy questions
that are directly germane to keeping one globally connected Internet - it’s simply
important that it do so deliberately rather than implicitly under the guise of purely
technical activity.

/John

Disclaimer: my views alone -  shared freely and worth every penny.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 13:53:20 +0100

(Changed the subject line to try avoid giving Fred additional
heartburn:-)

> This is a good discussion to have.

Agreed. Now and then the IETF does have discussions where someone
says "that's just politics and we don't/shouldn't do that" and if
we had a thread (or something) to point at with a calm discussion
of just that it might be useful. That said, I'm not sure that hrpc
is exactly the right venue for that discussion, (not all political
things being about human rights) but I can't think of a better one
either so...

>> RFC7258 is of course also relevant to areas of policy that are
>> rightly called political, but the text itself is not well described
>> as a political statement - it's a technical statement with policy
>> consequences.
> 
> The political statement it makes is that the ability of two parties
> to communicate without observation ("privacy") is more important than
> anyone else's ability to monitor that communication (it is an
> "attack"), as a property of the Internet. To many people and in many
> jurisdictions, that is an unavoidably a political assertion.

I don't think that characterisation of 7258 is quite right, and
in a way that affects the conclusion that you say many people
may reach. (I do agree with you that some folks do reach that
conclusion, but I think they're mistaken.)

7258 is not about two parties, it is about pervasive monitoring
of many parties in many places (physical & topological) over
extended durations. And I think 7258 does make the technical
case for why PM is an attack. I won't repeat the arguments here,
but some of that is not about privacy, but more about security.

7258 does not actually say that privacy is more important than
anyone's ability to monitor one connection between two parties.
And I think that is correct - I don't think there is a credible
purely technical justification for such an unqualified statement
about two parties and privacy trumping all monitoring.

That said, I'm personally in favour of IETF technologies being as
privacy-friendly as is pragmatically possible, so that implementers
and those-deploying get the choice to be privacy-friendly and aren't
forced to use protocols that prevent them from doing so. But I don't
claim that we have a documented IETF consensus that goes quite that
far. (I'd guess we might be able to reach consensus something along
those lines though.)

Is my position there political or technical? I guess I'd say it's a
technical argument, but others might disagree. And of course that's
not easy to figure out as many IETF participants are clever folk
who are well able to construct a good technical argument for what
they want, regardless of whether their motivation is commercial,
technical or political. I think it's good that we don't argue
about folks' motivations but about their technical arguments, so
I'm not too bothered that we can't always tell why someone is
making an argument. (Maybe taking that attitude is a political
statement though;-)

> 
> Note that I don't think that RFC7258 is bad, nor is making such a
> statement as the IETF. If we were to avoid doing so, we'd be
> hamstrung; there's very little that we could argue for or against
> doing in protocols, because someone would object -- whether that be
> governments, operators, vendors or users. The IETF works because we
> have a broadly shared idea of what "fit for purpose" means for the
> Internet, and Pervasive Monitoring didn't fit into that.
> 
> What's important is that we followed our documented, open consensus
> process in publishing that statement, and that we made sure it was
> relevant to our work. Some people think that RFC was overreaching;
> others think it didn't go nearly far enough, so it's probably about
> right.

I agree with the two paragraphs above.

>> To try use an analogy to explain - a document describing weather
>> patterns ought not be considered political, but deciding how to
>> deal with global climate change clearly is. Some IETF documents are
>> like the former.
> 
> I think that's a poor metaphor; weather patterns are documenting
> something that occurs (sometimes naturally, sometimes manmade); the
> document *describes* the weather patterns, it does not define them.
> IETF documents (at least good ones) document protocols that are
> agreed to by implementers during the process of their definition.
> They have an opinion about how the world should work, even if their
> authors refuse to admit so.

Fair enough, all analogies are misleading in some respect.

What I was trying to get to was a difference between an RFC that
has policy implications and the later use of that RFC in political
argument. Just because the latter happens does not mean that the
RFC is itself a political statement. So for example, I don't think
7258 is a political statement, but if someone printed it out and
nailed it to the door of Fort Meade, that latter act would be a
clearly political statement I reckon.

In the case of 7258, (and 2804 iirc) part of the discussion did
explicitly consider that the eventual RFC would likely be used in
such political argument and we did make some text changes to try
ensure that was less likely to be misinformed but I still don't
consider that making a political statement, rather we were trying
to make the technical statement in a way that would hopefully lead
to less confusion later.

Cheers,
S.

> 
> Cheers,
> 
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
>

---

From: John Curran <[email-masked]>
Date: Fri, 3 Jun 2016 09:29:04 -0400

On Jun 3, 2016, at 8:53 AM, Stephen Farrell <[email-masked]> wrote:
> (Changed the subject line to try avoid giving Fred additional heartburn:-)

:-)

(Fred has enough to deal with already, and we should definitely be nice to him.)

> case for why PM is an attack.

RFC7258 makes a well reasoned argument that the actions required to
conduct PM are indistinguishable regardless of motivation or legality,  and
that therefore defense against nefarious PM actors by the IETF requires
that PM be mitigated in general.   (I’ll avoid using the word “attack” at all,
since the RFC redefines that word from its common usage.)

The technical analysis of whether it is possible to make legal PM somehow
distinguishable is absent.  The technical analysis of whether protocols could
reasonably be augmented to collect “legal” monitoring data and escrow it for
"exceptional access" is absent.  Given that some governments presently have
public policy requirements that involves pervasive monitoring, it would have
been nice to include some analysis and then technically describe why these
can’t be accommodated and hence will be mitigated along with nefarious PM.

As it is, the public policy requirement of legal PM is simply set aside, without
any clear technical treatment, and that definitely makes it look like RFC7258
takes a particular political stance with regard to pervasive monitoring.  (As an
aside, I’m not certain there’s anything wrong with the IETF taking a political
stance that clearly supports a globally connected and safe Internet, so long
as it is clear that it is doing so and overly inclusive during the development
process.)

> technical or political.

> to make the technical statement in a way that would hopefully lead

Agreed, but the present doc doesn’t really provide any technical analysis
regarding why it is not technically possible to provide “legal” PM; it is more
of a footnote to the effect that presently it can’t be distinguished so it will
be have to be mitigated as well.   Since there was no consideration of how
to deal with the requirement of legal PM (not even a note to the effect that
it would be technically very complex to provide such), you really shouldn’t
be surprised by characterization that the document takes a political position.

/John

Disclaimer:  my views alone (no one else would claim them anyway ;-)

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jun 2016 09:55:43 -0400

Hi,

The Mission of the IETF makes clear that from time to time we may need
to make political statements in support of that mission.  The question
here is whether making statements or inserting selection criteria about
venues supports the mission of the IETF.  The risk is that going beyond
the mission will trade off assets and effort against it.  To draw this
starkly, does the IETF want to be viewed as a global standards
organization or a human rights organization?  All of this applies to the
iEtf and not the iRtf.  This RG has for more latitude to explore human
rights and their relationship to the IETF's work (or for that matter
other SDOs- as an aside, it would be helpful if any output were more
generally applicable).

The challenge for this research group is to find ways for us to act
ethically in fulfilling the mission, or failing that, explain what we
need to do to change that mission.  draft-tenoever-hprc-research-02
provides an evaluation of our protocol stack on the basis of human
rights.  The chartering of the RG all but demands such a draft.

This having been said, I find something troubling in the document.  It
seems to cover SOME human rights and not others.  The rights in the UDHR
themselves conflict, and I would expect that conflict to be reflected. 
For example, while the document spends a substantial amount of time on
privacy and freedom of expression, it spends considerably less time on
the basic rights to life, liberty, and security of the person (Article 3
of the UDHR).  What does "security of the person" mean in the context of
our protocol work, and how does it interact the right to freedom of
opinion and expression (Article 19) in the context of our protocol work?

That is something I would expect to see, and I very much doubt that
there will be black and white answers.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 20:28:04 +0100

> can’t be accommodated and hence will be mitigated along with nefarious PM.

I find that argument utterly unconvincing. 7258 is not the place to
provide a non-existence proof against the kind of magical thinking
that would be necessary to defend "good" PM as distinguishable from
"bad" PM (for any definitions of good or bad).

Also, I've no clue what you mean by "legal PM."

> be surprised by characterization that the document takes a political position.

I never said I was surprised:-)

FWIW my sense of where you're coming from is that perhaps what you're
saying is that anything we know is likely to be interpreted as a
political statement (in this case by those who do PM, or perhaps PM
or LI) itself then becomes a political statement.

Is that in the ballpark? (If so then I of course also reject that
idea, but I'd then understand more about where we're not on the same
page.)

Cheers,
S.

---

From: John Curran <[email-masked]>
Date: Fri, 3 Jun 2016 15:55:46 -0400

> "bad" PM (for any definitions of good or bad).

Really?  I believe you rely upon that very inability to distinguish them in order to
come to the technical conclusion that all PM must be treated as an attack and
possibility for mitigation considered during protocol design.

Either you’re relying on that completely undocumented technical constraint, or
you have dismissed the requirement for legal PM entirely out of the very realistic
public policy issues that it poses.  It appears the latter, and thus I recommended
that cases where public policy positions are taken be more clearly called out in
future IETF documents.

> Also, I've no clue what you mean by "legal PM.”

See RFC7258 - "… PM can range from non-targeted nation-state surveillance,
to legal but privacy-unfriendly purposes”

> Is that in the ballpark?

Not at all - I’m saying that you’ve ruled out any possibility of PM for “legal
but privacy-unfriendly purposes” without showing why that result is the only
viable technical outcome, so the result isn’t a technical conclusion but based
on some “desirable" public policy result.  Again, it’s probably a very useful
result for maintaining a globally interconnected and secure Internet, so long
as the IETF makes it plain during development that it is undertaking public
policy.

/John

Disclaimer:  my views alone - digitally signed collector copies available on request.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 21:06:46 +0100

On 03/06/16 20:55, John Curran wrote:
> Really?  

Yep.

> I believe you rely upon that very inability to distinguish them in order to

Yes. What's utterly unconvincing is your argument that the lack of a
proof of that makes 7258 political.

> to legal but privacy-unfriendly purposes”

I think I get what you mean now thanks - the likes of mega-companies
driven by advertising:-)

S.

---

From: John Curran <[email-masked]>
Date: Fri, 3 Jun 2016 16:55:59 -0400

> proof of that makes 7258 political.

Stephen -

RFC7258 provides a particular direction for IETF protocol developers -
direction which will, over time, hinder/limit/preclude use of PM for legal
purposes.  Absent technical explanation of why that outcome is necessary,
it actually is a statement which takes a public policy position.   Frankly, it
is a valuable service to the Internet community for the IETF to make such
a clear policy statement, but definitely needs to be done explicitly and with
corresponding outreach if one wants a multistakeholder result (e.g. a final
outcome which governments understand and support, rather than subvert
due to lack of investment in the process.)

IETF protocol engineers should not have to work on protocols that have
objectionable elements, particularly when such elements hinder the growth
and security of the global Internet.   It is reasonable for the IETF to state
whatever norms and values it feels are necessary for a successful Internet,
but such statements are not technical if they preclude one alternative over
another while lacking technical justification for why it must be that way.
This is the case with RFC7258, and we’re likely to experience the same
difficultly is highly likely to occur when considering protocol considerations
necessary for supporting human rights, so it would be best if the scope of
the WG activity made plain whether taking specific public policy positions
is in scope.

/John

Disclaimer: my views alone, but now shared for everyone - CC0 applies.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jun 2016 17:01:24 -0400

Hi,

A cautionary note: we seem to be arguing over an RFC that has been out
for quite some time, and cannot change.  What may be getting lost is the
principles.  With that in mind, please see below.

> proof of that makes 7258 political.

Whether 7258 is political is not the right question, because the readers
gets to decide that matter, not the authors.  The important question is
whether 7258 is supports the mission of the IETF in some way.  If we
choose to publish a document, regardless of how people view it, we will
have credibility with the broader community if we support it with strong
technical underpinnings.  References are a good means to provide that
support, and they add to transparency regarding our decision making
process.  And I would add that if one of your students made an
unsupported assertion in an academic paper, you might well mark her or
him down for it, regardless of whether the assertion was political.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 22:08:03 +0100

On 03/06/16 21:55, John Curran wrote:
> purposes. 

Yes, hopefully so.

> Absent technical explanation of why that outcome is necessary,
> it actually is a statement which takes a public policy position. 

Yes, we disagree about that. I think 7258 provides sufficient
and appropriate detail (which is mostly to omit detail).

But generalising away from 7258 - is it your contention that
unless relevant RFCs contain all detail of everything fully laid
out and justified (via included text or by reference) that they are
then political statements? I don't think that's at all credible as
it would call for all such RFCs to be written as precisely as a
PhD thesis, which is not appropriate IMO.

>  Frankly, it

s/WG/RG/

As an IRTF RG I think comment on HR aspects of IETF processes is
in scope. Changing those processes is not in scope here.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 22:13:54 +0100

Hiya,

On 03/06/16 22:01, Eliot Lear wrote:
> gets to decide that matter, not the authors. 

It is the question that was asked however. And while it may not be
the best question, it gets asked from time to time about various
things, and I think it'd be an improvement if we had some better
clarity about what that question might mean and what answers might
make sense.

> The important question is

Well no, as I said in my response to John, RFCs are not PhD theses.
They need to be correct, but don't require the same level of precision
in how every statement is justified.

S.

---

From: John Curran <[email-masked]>
Date: Fri, 3 Jun 2016 18:16:51 -0400

>> direction which will, over time, hinder/limit/preclude use of PM for legal

Yes, while I do believe it would be possible to guide future protocol
developers to somehow allow “legal PM”, it is unclear if that could
be accomplished in any meaningfully secure manner; it is unlikely
that the capability would be useful in criminal matters (since criminals
would simply disable or use something else); and there exists a very
large probability of misuse of the “exceptional access” that would be
provided to the PM data/collection mechanism.

Of course, nearly all of the above is a political statement - a particular
position on public policy matters based on what I happen to feel is best…
There’s nothing wrong with that as a basis for recommendation to all
IETF protocol developers, but if that’s the reason, it deserves to be
stated as such.

> and appropriate detail (which is mostly to omit detail).

Acknowledged - different views are inevitable and welcome
(particularly when we can identify the difference so clearly)

> then political statements?

Not at all…

> I don't think that's at all credible as

Agreed, but for those situations where the IETF decides to guide all future
protocol developers with regards to a particular architectural approach that
will mandate specific public policy outcomes for the all Internet protocols to
come, then it is quite important to either clearly state the public policy goals
which drive the recommendation, or to clearly demonstrate why there is only
one technical approach available.

Thanks,
/John

Disclaimer: my views alone - do not consume before removing wrapper.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 23:33:27 +0100

I think we're getting repetitive so I'll let others chime in
as they see fit after this...

On 03/06/16 23:16, John Curran wrote:
> Of course, nearly all of the above is a political statement 

I'm afraid I still disagree. It may not have all the argument
in that paragraph but that does not make it a political
statement.

S.

> - a particular

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jun 2016 20:50:59 -0400

> clarity about what that question might mean and what answers might

The problem is that it really is open to the interpretation of the
reader, no matter what you or I might conclude, but okay...

> in how every statement is justified.

As I understand it one of the reasons for going to DOIs for RFCs was so
that academics could more easily receive publication credit.  If the
quality of the work doesn't warrant that recognition, a DOI isn't going
to save us.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Jun 2016 20:55:49 -0400

> IETF protocol developers, but if that’s the reason, it deserves to be

It is a political claim when you state it in explicitly political
terms, perhaps.  But the very same propositional content can be made
entirely neutrally about the technology:

    The problem with attempting to distinguish desirable monitoring
    from undesirable monitoring in a network of networks is
    fundamentally technological.  In a network of networks, the end
    points and possibly some of the intermediate connecting systems
    are controlled by the very targets of monitoring.  Those end
    points are in a position to choose the mechanisms for and
    configurations of communications between them.  Therefore, any
    system that did not wish to be monitored would not use the
    monitorable technology.  Moreover, an attacker on the network who
    wanted to monitor traffic without authorization would simply
    pretend to be an authorized monitor.  By implication, then, if it
    is desirable that communications must sometimes not be monitorable
    by an unauthorized third party, then the capability to foil such
    monitoring must be available.  If it is available, there is no
    reason to suppose it would not be in use all the time.  Therefore,
    distinguishing between desirable and undesirable monitoring in the
    network is futile.

None of that is about politics.  It is about the simple entailments
given a set of assumptions about the technology.  You might argue that
the result of this will be to push governments against the idea of a
network of networks.  And that may be, but that result does not make
the above political.  It just makes it an inconvenient truth for some
people.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Jun 2016 01:56:15 +0100

> reader, no matter what you or I might conclude, but okay...

So what's the consequence of that position? Is it that the
IETF cannot make "political statements" because only readers
decide what is or is not one such? I'd find that a bit hard
to accept, and would be surprised if that were your conclusion.

> quality of the work doesn't warrant that recognition, a DOI isn't going

I don't think mechanisms for referencing have anything to do
with the requirements for the precision of text in RFCs, nor
does academic credit. And neither is anything to do with the
question at hand. But in any case yes, DOIs won't save us:-)

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jun 2016 22:42:47 -0400

Hi Stephen,

> to accept, and would be surprised if that were your conclusion.

Taken with what I wrote earlier, the consequence of that position is
that the IETF SHOULD makes "political statements" (for whatever
definition) when they support the mission of the organization, and they
SHOULD NOT make "political statements" (for whatever definition) when
they would be outside that mission.  That is why I feel quite
comfortable supporting 7258.  While one might quibble over the word
"secure" (and I have), clearly an unauthorized individual reading
content they shouldn't have access to has to fall outside that
category.  Is that a political statement?  My answer: who cares?  It was
necessary to guide development of IETF protocol specifications.

Again, this is relevant to this RG because it can provide bounds as to
how far to go with recommendations for the IETF.

> [...]

You are missing my point: Heather is working hard to see that the work
can be cited for academic credit, and you are essentially saying that
the standard of an RFC should be below the level that academics use. 
That's a conflict.

Putting that aside, I just flat out disagree with you that the
referencing standard for an RFC should lower than an academic paper. 
Again, doubly so when we are not solidly within the scope of the
organization, but somewhere in a grey area.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Jun 2016 12:51:11 +1000

> making an argument. (Maybe taking that attitude is a political

I think your reasoning is internally consistent, but will fail to convince many :)

> to make the technical statement in a way that would hopefully lead

Fair enough. It's probably not productive to focus too much on 7258. 

To me, the interesting question is how we determine the goals for a protocol; how much value it should place upon privacy, ability for authorities to intermediate, etc.

In some cases, there is precedence to guide us. In Honolulu, we didn't allow an on-path intermediary to insert itself into TLS for HTTP, despite the fervent wishes of some members of the community, because the HTTPS URL scheme is explicated defined as end-to-end, and so it would violate the reasonable expectations of current users of the protocol. Personally, I'd like that principle -- that you can't change protocols in a way that seriously violates the reasonable expectations of current users -- clearly enshrined (and there *is* technical justification for it, in a way; it's just a form of clear versioning).

In other cases, it's less clear. If someone brings the Foo Protocol to us and it allows a government to insert itself in its citizens' communication (their consent is assumed by using the protocol), should we reject it? Upon what rationale? 

If Bar Protocol is then designed to frustrate employers, schools, prisons and governments from knowing anything about what's happening, I'm imagining it will have many supporters, but if we've previously rejected Foo, accepting Bar will be seen by many as a political statement. Again, that might be the right thing to do, but we'd better be prepared for the repercussions.

From more personal experience, the "safe" hint for HTTP was designed to give end users (or their parents) easier control over the content they were exposed to online, but one of the objections that came up in IESG discussion was that this might have a secondary effect of increasing censorship (the exact mechanism posited is still not convincing to me). Regardless of how you feel about that, however, upon what basis do we make such judgements?

Cheers,

---

From: [email-masked]
Date: Sat, 4 Jun 2016 01:51:18 -0400

So how long before the spammers, errr excuse me, the Direct Marketing
Association and similar -- you know, the folks who kept showing up
before Congress during the debates about CAN-SPAM trying to "loosen"
provisions in favor of email advertisers -- and succeeding in some
cases -- show up or pull the IETF into court or hearings over RFCs
which they claim violate 7258 inter alia?

   https://thedma.org/

I know, now you want to argue the case with me, you want to say it's
all voluntary, We Have Heard All That 10,000 Times Before! Save your
bits.

A court, or even congress, or the EU, etc, may not accept that easy
prestidigitation which plays so well to the amen chorus.

Be careful what you wish for.

This all requires a lot more study and wisdom than I'm seeing in this
discussion. It's all so...blue-sky: So long as those present get to
define how the world works this is all reasonable discourse.

Why not at least get some voices with a likely very different PoV into
the discussion. Perhaps DMA counsels and lobbyists, big data miners,
US DoJ, NYC DA Cyrus Vance, Jr -- he's been very outspoken on
cryptography issues, FBI's Comey also, this isn't that (crypto) per se
but I'd imagine they could muster an opinion on "PM" RFCs, KSA, Iran,
China, RU, India, Turkey, etc. etc. Maybe even some respectable big
thinkers (int'l law professors, ethicists, etc.)

Not to give them a "vote" (I know I know) per se but to invite some
more varied viewpoints.

I just get the feeling this can all backfire big-time.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Jun 2016 10:33:18 +0100

On 04/06/16 03:51, Mark Nottingham wrote:
> To me, the interesting question is how we determine the goals for a
> protocol; how much value it should place upon privacy, ability for
> authorities to intermediate, etc.

Sure, these are good questions to explore. I'm sure I don't
have the good answers they deserve tbh.

> 
> In some cases, there is precedence to guide us. In Honolulu, we
> didn't allow an on-path intermediary to insert itself into TLS for
> HTTP, despite the fervent wishes of some members of the community,
> because the HTTPS URL scheme is explicated defined as end-to-end, and
> so it would violate the reasonable expectations of current users of
> the protocol. Personally, I'd like that principle -- that you can't
> change protocols in a way that seriously violates the reasonable
> expectations of current users -- clearly enshrined (and there *is*
> technical justification for it, in a way; it's just a form of clear
> versioning).

Right. Another aspect of that is that many of the proposals
for TLS MitM involve taking a two party protocol (not counting
CAs for the moment) and try turn it into a 3 party protocol,
which is a very different beast security-wise and in many other
respects. So as you say, radical changes to the existing
semantics is often a good reason to reject a proposed change.

> 
> In other cases, it's less clear. If someone brings the Foo Protocol
> to us and it allows a government to insert itself in its citizens'
> communication (their consent is assumed by using the protocol),
> should we reject it? Upon what rationale?
> 
> If Bar Protocol is then designed to frustrate employers, schools,
> prisons and governments from knowing anything about what's happening,

Yeah, those can be tricky and I'm not sure how we generalise.

> I'm imagining it will have many supporters, but if we've previously
> rejected Foo, accepting Bar will be seen by many as a political
> statement. Again, that might be the right thing to do, but we'd
> better be prepared for the repercussions.
> 
> From more personal experience, the "safe" hint for HTTP was
> designed to give end users (or their parents) easier control over
> the content they were exposed to online, but one of the objections
> that came up in IESG discussion was that this might have a
> secondary effect of increasing censorship (the exact mechanism
> posited is still not convincing to me). Regardless of how you feel
> about that, however, upon what basis do we make such judgements?

I just re-read the IESG comments on that. [1] Those are kind of
all over the map really, as I think was the IETF LC (I didn't go
look back at that). Perhaps that is good evidence that we're
operating in a half-understood space when it comes to issues related
to privacy impacts, not sure.

Anyway, I'll need to ponder all of the above some more before
I'd be confident in attempting real answers.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ballot/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Jun 2016 10:33:39 +0100

On 04/06/16 03:42, Eliot Lear wrote:
> they would be outside that mission. 

So your take then is more like "I know it when I see it, and
that's a good enough definition"? That's consistent and maybe as
good as we'll get perhaps but it'd mean that there's no generic
way we can help the discussion if someone claims some draft is
"just political" and hence oughtn't be published as an RFC.

> That is why I feel quite

I think "RFCs as (sort of) academic publications" is a side discussion
and probably distracting, but it's just not the case that RFCs
need to the same as academic publications. If they were the same
90% of RFCs would be claiming to be better than anything that
went before for example:-) My point was only that I don't find
John's claim that "lack of detail => political" is credible.

S.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 4 Jun 2016 09:52:47 -0400

> "just political" and hence oughtn't be published as an RFC.

I wouldn't put it that way.  While perhaps an imperfect analogy, another
way of looking at this is the BoF question from RFC 5434:

>       - there is a problem that needs solving, and the IETF is the right
>         group to attempt solving it.

And so what does it mean for the IETF to be the right group to address
anything?  That is where our mission comes in. 

And so there are really two questions:

  * Whether the IETF says anything at all on a subject; and
  * While doing work we've agreed to do, what are the ethical
    implications of design choices?

The first question, I would argue, is relatively straight forward. 
There are relatively few instances in which there are gray areas. 
Nobody comes to us for arms control treaties or to settle territorial
disputes, nor should they, nor should we go there as we lack any
competence at addressing such matters, and it is not clear whether our
decision process of rough consensus would be appropriate in those
cases.  Our mission scopes the work of the IETF as I previously
described, for which our decision process is appropriate and where we do
have competence.

What's more, quite frankly companies won't spend money to send
individuals to IETF meetings if they think that there is little
likelihood of getting work accepted.  That's called a bad investment. 
As we veer from the mission, those who seek to accomplish it will take
their business elsewhere.  We are not human rights experts even though
we as individuals have ethical responsibilities regarding human rights. 
Even if we adopt a code of conduct such as ISOC's [1], that is a
personal code, and must let people answer those questions for themselves
in as much as many technologies are used to serve both good and ill.

> John's claim that "lack of detail => political" is credible.

The point is that "lack of detail" => "unsupported", and when we are
outside our core mission, then why would our unsupported assertions be
valued above other's?

Eliot

[1] http://www.isoc.org/members/codeconduct.shtml

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 7 Jun 2016 07:41:37 -0400

A late comment here: a number of us would question if any PM could be
legal... this is something about which many of us in civil society disagree
with our own and other governments. Anyway, not sure I have much more to
add other than to agree this RG is a good place to have discussions but we
do want to make sure feedback about mtgvenue makes it back to that list
(E.g., the paragraph text suggestion)

On Friday, June 3, 2016, John Curran <[email-masked]> wrote:

> On Jun 2, 2016, at 9:12 PM, Fred Baker (fred) <[email-masked]
> <javascript:;>> wrote:
> >
> >> On Jun 2, 2016, at 5:47 PM, John Curran <[email-masked]
> <javascript:;>> wrote:
> >>
> > ...From my perception, if we're dealing with a party that will analyze
> and overcome any reasonable technical obstacle we set up, technology isn't
> the solution. Yes, we recommend encryption in any and every case that it
> makes economic sense. But ultimately someone needs to say "enough!".
> >
> > RFC 7258 is the IETF's way of saying "enough". You're correct that we
> didn't go through all of the hoops we do with technology problems, but I
> actually think we correctly recognized that this was not a technology
> problem, nor was it solvable by technology. And if that's political, so be
> it.
> >

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 7 Jun 2016 16:33:54 +0200

On 06/03/2016 02:53 PM, Stephen Farrell wrote:
> Is my position there political or technical? 

This has been a fascinating discussion so far. I think the question here
asked by Stephen is exactly where I would object. I think the technical
_is_ political. It is not a dichotomy.

The way we build the Internet infrastructure has implications on human
rights, whether it is intentional or not. And the human rights protocol
consideration are a way to make this visible and help us navigate that.

There are no definitive answers here, but making the implications
visible will help guide us making decisions (that we could later revise
if we have other insights).

Best,

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 7 Jun 2016 16:44:43 +0200

On 06/03/2016 03:55 PM, Eliot Lear wrote:
> organization or a human rights organization?  

I don't think anyone here want to turn the IETF into a human rights
organization, but as the special rapporteur for freedom of expression
has notes, the IETF has an impact on human rights.

It is also stated in RFC3935:

   The Internet isn't value-neutral, and neither is the IETF.

> All of this applies to the
> seems to cover SOME human rights and not others.  

That is because some rights have a relation to Internet protocols,
whereas others may not.

> The rights in the UDHR

This is an issue for the content layer, not the protocol layer imho.

> there will be black and white answers.

I completely agree that there will not be black or white answers, but
hopefully this will provide us a framework to discuss.

Best,

Niels

---

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Jun 2016 16:58:08 +0200

Hi Niels and thanks for your reply.  Please see below.

>    The Internet isn't value-neutral, and neither is the IETF.

Totally agree.  I just wanted to explain where I think the bounds of the
discussion are, and where the expertise of the organization is.

> That is because some rights have a relation to Internet protocols,

But I think it would be helpful if there were discussion about that,
particularly has relates to Article 3.  Now- maybe it's simply my lack
of understanding of the scope of Article 3, but as I mentioned below, I
would imagine there is some conflict.  See below for more.

> This is an issue for the content layer, not the protocol layer imho.

Is it really that clear cut?  Is the MIB that handles lawful intercept
at the content layer or the protocol layer, for instance?  Which layer
is encryption at?  Is the IP address not a useful datum for law
enforcement (or other) authorities or criminals (for that matter)?

Eliot

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 11:05:52 -0400

> has notes, the IETF has an impact on human rights.

Absolutely.  In fact, I would say that the choices (specifically including
Internet protocol technical considerations) of the IETF have a very real
and significant impact on ability to support human rights on the Internet.

>   The Internet isn't value-neutral, and neither is the IETF.

Indeed.  It would be good to be very explicit about those values.

> That is because some rights have a relation to Internet protocols,

Are you suggesting that the human rights not included in the document
are not affected by the IETF’s technical considerations?   it is quite
clear that is not the case - effective remedy can be directly impacted
by confidentiality; this is likely an inevitable tradeoff, which implicitly
prioritizes one human right over another, in keeping with the historic
stance of the Internet protocols.   There is nothing wrong with such a
tradeoff, but it should explicitly called out (unless you do not believe
that “effective remedy” is a human right.)

/John

Disclaimer: my views alone.

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 7 Jun 2016 17:44:56 +0200

> that “effective remedy” is a human right.)

Hi John,

Could you work out a case for this, because I am not so clear how this
would work. IETF or protocols cannot deliver effective remedy.

This is also exactly the reason why we dropped issue of the 'right to be
presumed innocent' from the document. This is effectively a right that
needs to enabled and respected by courts, not by the IETF or protocols.

The same holds true for effective remedy imho.

Best,

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 7 Jun 2016 17:49:45 +0200

> enforcement (or other) authorities or criminals (for that matter)?

I think we should have a clear differentiation here between the role of
the state (which is to protect and uphold human rights), and that of
non-state actors (which is to respect human rights).

It seems now we're going down the rabbit hole of how we should / could
assist LEAs and courts in upholding their human rights obligations. I
think we do not need to help them with that, they're perfectly able (and
obliged) to do so themselves.

Best,

Niels

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 11:58:09 -0400

> would work. IETF or protocols cannot deliver effective remedy.

In this case, the question is whether the IETF technical considerations
_hinder_ delivery of the right, not whether they support delivery of the
right.  The point is simply that confidentiality (and anonymity) are highly
likely to hinder the delivery of effective remedy for violations of personal
security on the Internet, and once that is accepted as a design constraint,
then this tradeoff is fine (and should simply be documented)

It’s not whether there are technical considerations necessary to support
effective remedy - it’s that there explicitly are not technical considerations
to support it because there are other human rights that take precedence
and whose technical considerations result in "effective remedy" being put
out of scope of the document.  The document can not be said to be any
comprehensive treatment if it doesn’t clearly address such an issue.

/John

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 7 Jun 2016 18:09:12 +0200

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 06/07/2016 05:58 PM, John Curran wrote:
> On Jun 7, 2016, at 11:44 AM, Niels ten Oever <[email-masked]

I think that is unclear here and dependent on the capabilities of law
enforcement.

> The point is simply that confidentiality (and anonymity) are highly 

I think you mean there is another outcome of the balancing of the
rights, as is for instance done in the Necessary and Proportionate
Principles [0], the Human Rights Council Resolution on the Right to
Privacy in the Digital Age [1] or the report by the UN special
rapporteur on Encryption and Anonymity [2].

In short: this is not a decision the IETF needs to redo. This has
already been discussed (and decided) in other fora. Replicating that
discussion here might make matters more complicated than needed,

Best,

Niels

> Disclaimer: my views alone.
[0] https://necessaryandproportionate.org/
[1]
https://www.hrw.org/sites/default/files/related_material/UNGA_upload_0.pdf
[2]
http://www.ohchr.org/EN/HRBodies/HRC/RegularSessions/Session29/Documents/A.HRC.29.32_AEV.doc

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 12:50:15 -0400

> discussion here might make matters more complicated than needed,

If you believe that the balancing has already been done in one of those
documents, then simply cite the appropriate document as the basis for
not considering the technical considerations for protocols with respect
to effective remedy/due process.

It’s fine to state that the appropriate tradeoff has already been made
elsewhere, but complete omission of the the human right of due process
from the considerations without an explanation why makes it appear as
if the IETF is choosing the appropriate balance.  There’s no doubt that
widespread use of encryption and anonymity will make determination of
jurisdiction rather challenging and preempt effective due process (short
of the IETF engaging with law enforcement/governments to determine
if there are technical solutions), but that’s not the IETF issue if others
have already performed that human rights balancing.

/John

Disclaimer: my views alone

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 17:57:04 +0100

> widespread use of encryption and anonymity will make determination of

Hang on. There's no widespread use of real anonymity, (as I'd define
it) and even speaking as if that's possible is very likely to mislead
here. So what do you mean? FB real names? Tor? I don't know.

> jurisdiction rather challenging and preempt effective 

And that's also (I think) misleading. The issues with jurisdiction
almost all apply even if all is in cleartext. If you claim otherwise
please justify that.

There are a number of real tensions/tussles but we need to ensure
we don't analyse things that aren't real if we're to reach good
conclusions.

S.

> due process (short

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 13:34:42 -0400

On Jun 7, 2016, at 12:57 PM, Stephen Farrell <[email-masked]> wrote:
> almost all apply even if all is in cleartext.

Yes, the issues with jurisdiction always apply.  However, the ability 
to determine jurisdiction for due remedy is made significantly more 
challenging if Internet protocols provide no visibility into content 
due to encryption (as they should) and do not provide for reliable
attribution of other communicating parties (as exists if Internet 
protocols consider the need for support for anonymous services
due to other human right implications.)

/John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 18:50:34 +0100

Hiya,

> due to other human right implications.)

I'm not at all sure I accept that that happens to any significant
extent where the reason for the problem assigning a jurisdiction
is solely down to encryption. Can you supply some specific real
examples though, maybe I'm missing something?

I note that you didn't answer my direct question as to what you
mean when you use the term anonymity, which you've done again just
there. Can you answer that? (I'd hate for us to waste time and cycles
on using that term to mean radically different things. And to save
you asking, I think use of something like Tor is required but not
sufficient to even approach anonymity.)

S.

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 14:44:05 -0400

On Jun 7, 2016, at 1:50 PM, Stephen Farrell <[email-masked]> wrote:
> is solely down to encryption.

Solely?   Perhaps not solely, but that’s not what I said… I said “made
significantly more challenging if Internet protocols provide no visibility
into content”

> Can you supply some specific real

For example, a website selling ‘knock off” pharmaceuticals results in someone
dying due to bad product.  It is safe to assume that law enforcement will pursue
the payment and shipment processes, but if they want catch the actual culprit
who has setup and administering the sales website at a hosting center, it is made
far more difficult than simply obtaining a order against the hosting center so they
may monitor all traffic to/from the server in question.  Even having obtained a lawful
order to access such traffic, the use of encryption (ssl for the admin, https for the
buyers) and ready use of VPNs makes it hard to determine who/where is the criminal
and who might also be at risk.  Directly accessing the server may get you enough
info to identify other customers who may also be at risk, but you’ve then warned
the culprit that you’re on to them.

The point is that it is fairly easy to provide scenarios where encryption can
impede law enforcement in determine the parties and their jurisdiction,
and that might be “just the way the Internet works” (and should work), but
why that is a fair tradeoff should be included in comprehensive document
on considerations for Internet protocols and their impact on human rights.

> sufficient to even approach anonymity.)

Please…  VPN’s are the tool of choice for providing anonymity on the
Internet today; chain through two or three of them in different countries
and the legal hurdles required to unwind them results in process timeout
nearly every time.   Mind you, not everyone is up to doing the legwork
involved in a multiple VPN chain, just as there are common criminals
who do not make use of Tor-based solutions.

The draft in question states:

5.3.2.1.9.  Anonymity

   Question(s): Did you have a look at the Privacy Considerations for
   Internet Protocols [RFC6973], especially section 6.1.1 ?

   Explanation: Anonymity refers to the condition of an identity being
   unknown or concealed [RFC4949].  It is an important feature for many
   end-users, as it allows them different degrees of privacy online.

   Example: Often standards expose private information, it is important
   to consider ways to mitigate the obvious privacy impacts.  For
   instance, a feature which uses deep packet inspection or geolocation
   data could refuse to open this data to third parties, that might be
   able to connect the data to a physical person.

   Impacts: - Right to non-discrimination - Right to political
   participation - Right to freedom of assembly and association - Right
   to security
and is silent about the potential _impact_ on ability to provide due process
resulting from the use of anonymous protocols.  Again, it may be the case
that this tradeoff is already deemed appropriate via other globally accepted
norms and standards (we’ll leave Niels to find the appropriate references)
but a comprehensive review of technical issues to be considered by protocol
developers and their human rights impact should include clear guidance in
any case.

Thanks,
/John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 19:58:50 +0100

> significantly more challenging if Internet protocols provide no visibility

Ok, so do we agree there are no such cases that we can point at?

> on considerations for Internet protocols and their impact on human rights.

In the above example, absent use of multiple VPNs/Tor or similar the
IP addresses are very likely sufficient to identify the jurisdictions
involved. So things like TLS and SSH aren't relevant to this discussion
at all.

> who do not make use of Tor-based solutions.

Correct. Except the reality aiui is that very few people are using
multiple VPNs or Tor. Many people use one VPN (presumably for reasons
associated with copyright protection) but I've not heard any credible
report that many people use multiple VPNs. And if say the user base
of Tor is a couple of million people then we are clearly not in a place
where ciphertext contributing to difficulties in assigning jurisdiction
is a hugely pressing problem.

So for now I don't accept that your particular concern is a significant
one. If someone produces some data my opinion might of course change,
but based on the argument so far you can colour me very unconvinced
that this is a pressing issue.

S.

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 15:35:21 -0400

> Ok, so do we agree there are no such cases that we can point at?

No Stephen, there are many cases where identification of jurisdiction (and
thus provision of due process)  are made significantly more challenging for
LEA due to encryption - what I said is that it is not clear whether that is solely
a factor.

> involved. So things like TLS and SSH aren't relevant to this discussion

1) Multiple VPN usage does occur - see below
2) IP addresses are not at assured to provide information about jurisdiction
    (please review again the European Cybercrime Centre(EC3) presentation
     I referenced earlier which discusses this exact problem.)

> report that many people use multiple VPNs.

You need to get out more -

	http://null-byte.wonderhowto.com/how-to/chain-vpns-for-complete-anonymity-0131368/ <http://null-byte.wonderhowto.com/how-to/chain-vpns-for-complete-anonymity-0131368/>

	http://security.stackexchange.com/questions/60871/vpn-tunnel-inside-other-vpn-tunnel <http://security.stackexchange.com/questions/60871/vpn-tunnel-inside-other-vpn-tunnel>

	https://security23.wordpress.com/2012/08/27/how-to-chain-vpns-for-complete-anonymity/ <https://security23.wordpress.com/2012/08/27/how-to-chain-vpns-for-complete-anonymity/>

	https://www.ivpn.net/privacy-guides/advanced-privacy-and-anonymity-part-8 <https://www.ivpn.net/privacy-guides/advanced-privacy-and-anonymity-part-8>

Mind you, this is just a quick handful public information out thirty pages of such - not anything
particularly hidden or underground (which is more likely resource for those who would commit
crimes via such setups...)

The IETF can do whatever it wants - including claiming that it wants protocol developers
to comprehensively consider human rights (but in truth just deigning to include the select
human rights it considers worthy.)  I believe it would be an intellectually stronger position to
make a conscious effort to specify which particular human rights particularly pose technical
issues germane to Internet protocol developers, and cite relevant global norms and standards
of public policy regarding why those particular human rights are included.

/John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 21:23:53 +0100

> You need to get out more -

So I can learn to be condescending? :-)

Which of those links has numbers of users?

My point is that you've not convinced me of the part that
confidentiality is supposedly playing here.

That there are (non IETF) combinations of IETF technologies
that can be used to make life hard for some LEA is not news.
Just as it is not news that attackers of all kinds will eventually
attack plaintext protocols as recently seen in OEM PC update
programs. I think we've rehearsed all the aspects of the
trade offs in that discussion sufficiently already tbh.

And anyway all of that is just in the noise when it comes to
the issues that exist with jurisdiction - trying to figure out
who has jurisdiction over a single transaction that covers many
countries in various totally legitimate ways (via DNS, cloudy
things, corporate VPN gateways, with content that is legal in
only some places etc.) is much more where it'd be interesting
to discuss jurisdiction. I figure that if governments came up
with something sensible for such normal cases, it'd then be a
lot easier to try figure out how to deal with the silk roads
of the world. Starting from the latter though and from worries
about encryption is just not a good way to approach the problem.

Cheers,
S.

---

From: John Curran <[email-masked]>
Date: Tue, 7 Jun 2016 17:03:27 -0400

> So I can learn to be condescending? :-)

Well, you did say “I’ve not heard any credible report that many people
use multiple VPNs.”…   my retort was only to point out that: a) it does
occur, and b) your sample size of 1 might not be indicative of its popularity,
unless you happen to be well travelled in the Internet’s shady underbelly…

> Which of those links has numbers of users?

None.  I’m sure there is a function of [ (experience), (consequences
of being caught) ] which could predict how popular such usage is…

> trade offs in that discussion sufficiently already tbh.

Indeed.

> to discuss jurisdiction.

Also agreed.

> I figure that if governments came up
> of the world.

They _can’t_…  they literally do not understand how the Internet and its
protocols work, and thus can only express their needs in terms of what
they’re trying to accomplish when fulfilling their obligations to the public
(I’m referring to LEA here - intelligence services are a very different animal)

We understand user requirements, even when poorly communicated, and
attempt to design Internet protocols which satisfy those needs.  Suggestions
that government should provide their technical requirements (rather than their
‘problem statement') when they generally don’t have the understanding of how
these protocols work results in no meaningful engagement…  and eventually
some form of ill-conceived lawmaking or regulatory overreach precisely
because “that’s the only way to get what they need.”   Such attempts are
often egregious in their reach and capabilities, again because they not the
product of actual balanced consideration of conflicting requirements (e.g.
identification of user address (bad) vs user jurisdictional location (better)).

With respect to draft-tenoever-hrpc-research, I think it’s perfectly fine to
declare out of scope any technical impacts to human rights _not specifically
considered_, so long as we actually clearly state such.  We just shouldn’t be
complacent that we’ve comprehensively addressed the human rights issue,
because frankly, the Internet fails horribly at supporting several significant
human rights (security of person, redress/due process for violations of same)
and will continue to do so unless/until there is fundamental consideration
given to doing otherwise (and not presently in scope for this effort, as far
as I can tell...)

/John

Disclaimer: my views alone - this message queued till the top of the hour
                   due to self-imposed rate limiting.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 22:27:42 +0100

> they’re trying to accomplish when fulfilling their obligations to the public

I do understand that there are significant challenges for folks
working for governments working with how the technical community
does it's business. That's maybe at it's hardest when governments
try to interact with the IETF, since we don't even have a concept
of membership.

> (I’m referring to LEA here - intelligence services are a very different animal)

My contention is that it'd be a mistake to try tackle explaining
how the Internet and jurisdictions interact with that use-case in
mind. Much better to try to figure out how to handle more normal
disputes I reckon.

S.