Subject: Re: [hrpc] IRTF Chair review of draft-irtf-hrpc-guidelines-10

From: John Curran <[email-masked]>
Date: Sat, 18 Dec 2021 08:05:20 -0500

On 7 Nov 2021, at 3:13 PM, Colin Perkins <[email-masked]> wrote:
> 
> The HRPC RG chairs have requested that draft-irtf-hrpc-guidelines-10 be published as an RFC on the IRTF stream. The IRTF publication process is described in RFC 5743, and comprises a review by the IRSG to ensure technical and editorial quality, followed by a check by the IESG to ensure the work does not conflict with IETF standards activities.
> 
> As IRTF Chair, I perform an initial review of all drafts submitted for publication on the IRTF stream before sending them for detailed review by the IRSG. This note provides my review comments, for discussion.

Colin - 

    Thank you for your efforts – I’ll respond to but one of your review comments (it being in an area for which I hold particular blame…) 

> Section 3.2.20 highlights the issue of Remedy, but without some examples, it’s difficult to understand how it can be applied to protocol design. 

    Excellent point - there’s been discussion on the mailing list at length on this topic, but we failed to provide a specific example within the draft. 

    I’d propose adding something along the lines of the following text at the end of 3.2.20 to help inform the reader of the general concern and tradeoffs involved – 

   Example: Legal remedy against phishing attacks sent via email could be greatly facilitated if clear 
   attribution of the responsibility entity originating the email was required by the protocol.  However,
   there is an inherent tradeoff between supporting the attribution necessary for reliable legal remedy 
   versus the protocol attributes necessary for supporting other key human rights (for example 3.2.10. 
   Anonymity,  3.2.6. Censorship resistance, etc.) – a tradeoff that on balance favors use unvalidated 
   email senders in the underlying mail transport protocol and leaving the choice of additional mail 
   security protocols to the user and/or implementation as desired. 

Again, thanks for thorough review!
/John

Disclaimer:  my views alone - may they be worthy of the electrons used in transporting them around the globe...

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Dec 2021 13:02:20 -0800

On Sat, Dec 18, 2021 at 5:05 AM John Curran <[email-masked]> wrote:

> The HRPC RG chairs have requested that draft-irtf-hrpc-guidelines-10 be
> published as an RFC on the IRTF stream. The IRTF publication process is
> described in RFC 5743, and comprises a review by the IRSG to ensure
> technical and editorial quality, followed by a check by the IESG to ensure
> the work does not conflict with IETF standards activities.
>
> As IRTF Chair, I perform an initial review of all drafts submitted for
> publication on the IRTF stream before sending them for detailed review by
> the IRSG. This note provides my review comments, for discussion.
>
>
> Colin -
>
>     Thank you for your efforts – I’ll respond to but one of your review
> comments (it being in an area for which I hold particular blame…)
>
> Section 3.2.20 highlights the issue of Remedy, but without some examples,
> it’s difficult to understand how it can be applied to protocol design.
>
>
>     Excellent point - there’s been discussion on the mailing list at
> length on this topic, but we failed to provide a specific example within
> the draft.
>
>     I’d propose adding something along the lines of the following text at
> the end of 3.2.20 to help inform the reader of the general concern and
> tradeoffs involved –
>
>
> *   Example: Legal remedy against phishing attacks sent via email could be
> greatly facilitated if clear *
> *   attribution of the responsibility entity originating the email was
> required by the protocol.  *
>
>
I'm not so sure that this is in fact true. Consider that phishing attacks
usually end up with the user
clicking on some Web site. Often those are HTTPS and therefore the sender
is attributed,
and yet the user is fooled. So, while I think it's possible that this is
correct, I don't think
the draft should state it this definitively.

-Ekr

*However,*
> *   there is an inherent tradeoff between supporting the attribution
> necessary for reliable legal remedy *
> *   versus the protocol attributes necessary for supporting other key
> human rights (for example 3.2.10. *
> *   Anonymity,  **3.2.6. Censorship resistance, etc.) – a tradeoff that
> on balance favors use unvalidated *
> *   email **senders **in the **underlying mail transport protocol and
> leaving the choice of additional mail *
> *   security protocols to the **user and/or implementation as desired. *
>
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: John Curran <[email-masked]>
Date: Sat, 18 Dec 2021 17:10:51 -0500

On 18 Dec 2021, at 4:02 PM, Eric Rescorla <[email-masked]> wrote:
> 
> On Sat, Dec 18, 2021 at 5:05 AM John Curran <[email-masked] <mailto:[email-masked]>> wrote: 
>    attribution of the responsibility entity originating the email was required by the protocol.  
> 
> I'm not so sure that this is in fact true. Consider that phishing attacks usually end up with the user
> clicking on some Web site. Often those are HTTPS and therefore the sender is attributed,
> and yet the user is fooled. So, while I think it's possible that this is correct, I don't think

Eric – 

<chuckle> I’ll avoid a diatribe on the quality of “attribution” that is provided via typical SSL web practices today, and 
simply observe that at best it provides identification back to a domain name rather than an actual human being. 

However, I do agree that the statement could be clarified in its depiction of the conflict that might be faced if a 
protocol required actual human attribution, despite the obvious benefit to  end-users in their pursuit of legal remedy. 

As such, a slightly clearer example might read as follows - 

   For example - legal remedy against defamation or cyberattacks sent via email could be greatly facilitated 
   if clear attribution of the person responsible for the contents of the email was required by the protocol.  

   However, there is an inherent tradeoff between supporting the attribution necessary for assured legal 
   remedy versus the protocol attributes necessary for supporting other key human rights (for example 3.2.10. 
   Anonymity,  3.2.6. Censorship resistance, etc.) – a tradeoff that on balance favors use unvalidated email
   senders in the underlying mail transport protocol and leaving the choice of additional mail security protocols 
   to the user and/or implementation as desired. 

Thanks!
/John

Disclaimer: my views alone.  100% recycled electrons used in this message.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Dec 2021 16:16:58 -0800

On Sat, Dec 18, 2021 at 2:10 PM John Curran <[email-masked]> wrote:

>>     I’d propose adding something along the lines of the following text
>> at the end of 3.2.20 to help inform the reader of the general concern and
>> tradeoffs involved –
>>
>>
>> *   Example: Legal remedy against phishing attacks sent via email could
>> be greatly facilitated if clear *
> <chuckle> I’ll avoid a diatribe on the quality of “attribution” that is
> provided via typical SSL web practices today, and
Yes, that's correct. But that's in fact the granularity of identity that
the Internet currently supports.
It's also the identity provided by DNSSEC, DKIM, etc.

As you no doubt know, attempts to provide a more "real world" identity,
such as EV certificates,
have not been successful.

However, I do agree that the statement could be clarified in its depiction
> of the conflict that might be faced if a
> protocol required actual human attribution, despite the obvious benefit to
>  end-users in their pursuit of legal remedy.
>
> *   For example - legal remedy against defamation or cyberattacks sent via
> email could be greatly facilitated *
> *   if clear **attribution of the person responsible for the contents of
> the email was required by the protocol.  *
>
> *   However, **there is an inherent tradeoff between supporting the
> attribution necessary for assured legal *
> *   remedy **versus the protocol attributes necessary for supporting
> other key human rights (for example 3.2.10. *
> on balance favors use unvalidated **email*
>    *senders **in the **underlying mail transport protocol and leaving the
> choice of additional mail **security protocols *
> *   to the **user and/or implementation as desired. *
>
>
Well, I suppose that this text is literally true, in that such a
requirement would be a problem for
anonymity and censorship resistance, but more seriously, it would just be
highly impractical,
given that it's not possible to identify the real world identities of large
fractions of Internet
domains, let alone people with accounts at those domains. So, the result
would be that
it would preclude most valid email, let alone spam email.

-Ekr

---

From: farzaneh badii <[email-masked]>
Date: Sat, 18 Dec 2021 19:18:58 -0500

I don't agree. I raised the challenges that legal remedies and attribution
could have for human rights here but we are at it again.
I am sure you don't want to add  "legal remedy against blasphemy" as an
example... so lets cross out defamation.
I have mentioned it over and over that legal remedy cannot be "greatly
facilitated" if clear attribution is possible. But maybe we should do
actual research not to discuss things based on our impressions of things.
Something I was hoping this group could facilitate.

Farzaneh

---

From: John Curran <[email-masked]>
Date: Sat, 18 Dec 2021 20:17:07 -0500

> On 18 Dec 2021, at 7:18 PM, farzaneh badii <[email-masked]> wrote:
> 
> I don't agree. I raised the challenges that legal remedies and attribution could have for human rights here but we are at it again. 
> I am sure you don't want to add  "legal remedy against blasphemy" as an example... so lets cross out defamation. 
> I have mentioned it over and over that legal remedy cannot be "greatly facilitated" if clear attribution is possible. But maybe we should do actual research not to discuss things based on our impressions of things. Something I was hoping this group could facilitate. 

I am unclear what research you believe is required; the present difficulties of real-world prosecution due to lack of attribution are quite well-known - 

"However, many, including experts in the Internet Society’s discussions, raise concerns with the use of digital signatures to enable traceability:

	• Digital attribution is not absolute and vulnerable to impersonation: To establish criminal liability, guilt has to be proven beyond reasonable doubt–a threshold that is hard to overcome, especially when impersonation online is so easy and pervasive. Proving that Person A, the user of Mobile/Computer A, actually sent those messages running a disinformation campaign is very difficult to prove even if law enforcement has the sender ID. Establishing whether the use of a person’s device is necessarily evidence of the person’s use of the device requires additional information.[9] Of even greater concern is that innocent users’ may be implicated in illegal conduct by cyber criminals that impersonate their sender ID. …”

–– Traceability and Cybersecurity Experts’ Workshop Series on Encryption in India”,  27 Nov 2020, <https://www.internetsociety.org/resources/doc/2020/traceability-and-cybersecurity-experts-workshop-series-on-encryption-in-india/>

"D. Accountability

Once norms are adopted and implemented there must be accountability for those who violate them. This raises the complicated issues of attribution and response, both of which have proven challenging in addressing cyber attacks.

To support a claim that a state or non-state actor has acted wrongfully requires credible attribution. This starts with collecting and analyzing evidence, and there is both technical and procedural work that can be done now to improve the quality and timeliness of attribution. More specifically, as with other technical disciplines, having well-accepted protocols for collecting and analyzing evidence is important to improving the quality of investigations. Thus, the standardization of investigative methods is important because it may reduce concerns over the integrity of evidence, even if attribution must be decided on a case-by-case basis. In addition to improving attribution as a technical matter, there is much that can be done to shorten the bureaucratic processes associated with making attribution decisions and then, when appropriate, making them public. The often long delay between an event and a declaration of responsibility is due, in no small part, to unclear or unwieldy processes for reaching such decisions at a national level and is exacerbated when several countries are involved in making collective attribution statements. Designing and exercising processes for reaching attribution at a national level and international level, and improving information sharing between countries, can significantly improve the timeliness and effectiveness of attribution statements and facilitate any further appropriate action.

Even after the evidence points to a given actor, the next step (attribution) may remain challenging. In the past, some state and non-state actors have asserted that attribution is impossible or required absolute proof. But absolute proof is not required and while attribution may be difficult, it is not as insurmountable as some have suggested. In the nation state context, attribution, whether in the cyber or physical realm, is often a political act, and while there is no particular agreed upon standard of proof, countries still have a strong incentive to not make spurious allegations, lest they lose credibility. In short, what is needed is for attribution to be convincing to other countries and to the public.

–– “ ADVANCING CYBERSTABILITY, FINAL REPORT, NOVEMBER 2019”, Global Commission on the Stability of Cyberspace, <https://cyberstability.org/report/>, 

Or feel free to speak with nearly anyone in law enforcement with regard to the present challenges in legal remedy due to lack of attribution… These challenges are rather perfectly obvious given the circumstances and have been well-documented by the cybersecurity when it comes to post-incident remedy and enforcement. 

FYI,
/John

Disclaimer: my views alone.

---

From: John Curran <[email-masked]>
Date: Sat, 18 Dec 2021 20:43:54 -0500

> On 18 Dec 2021, at 7:16 PM, Eric Rescorla <[email-masked]> wrote:
> ...
> Yes, that's correct. But that's in fact the granularity of identity that the Internet currently supports.
> As you no doubt know, attempts to provide a more "real world" identity, such as EV certificates,

Indeed…  The tradeoffs in higher levels of validation haven’t generally proven worth the benefit. 

> Well, I suppose that this text is literally true, in that such a requirement would be a problem for
> anonymity and censorship resistance, but more seriously, it would just be highly impractical,
> given that it's not possible to identify the real world identities of large fractions of Internet
> domains, let alone people with accounts at those domains. So, the result would be that

Again, I am in complete agreement.  The present difficulties with attribution are consequential to the decisions 
that have been made collectively in Internet deployment to date, and likely represent the best balance available
under the circumstances.   

Could we establish protocols and processes that change the status quo and address the attribution issue?  
Certainly, but as you note this would be a dramatic change (and, as noted earlier in the document, doing so
would have "potential adverse impact of attribution on the right to privacy and freedom of expression” and 
"enabling attribution on an individual level is most likely not consistent with human rights.”

It’s interesting how excited everyone gets as a result of us giving an example that states that today’s Internet 
email reflects the best balance of protocol attributes to maximize the human rights and that attribution isn’t 
worthwhile…  Can someone explain why putting that status quo in writing (as an example of appropriately 
balancing human rights-related protocol attributes) so contentious? 

/John

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Dec 2021 18:19:33 -0800

On Sat, Dec 18, 2021 at 5:43 PM John Curran <[email-masked]> wrote:

> Again, I am in complete agreement.  The present difficulties with
> attribution are consequential to the decisions
> that have been made collectively in Internet deployment to date, and
> likely represent the best balance available
> under the circumstances.
>
> It’s interesting how excited everyone gets as a result of us giving an
> example that states that today’s Internet

Can we refrain from inferring (and commenting on) people's emotional
states? In any case I don't think I'm getting particularly excited.

My point is that this is *not* an example of balancing human rights
attributes. Rather, it's that even if one discounted the right to privacy
and freedom of expression, requiring personal-level identification would
cause very serious operational issued for non-anonymous and largely
non-controversial communications, in much the same way that requiring EV
certificates universally would.

-Ekr

---

From: John Curran <[email-masked]>
Date: Sat, 18 Dec 2021 21:29:58 -0500

> On 18 Dec 2021, at 9:19 PM, Eric Rescorla <[email-masked]> wrote:
> ...
> My point is that this is *not* an example of balancing human rights attributes. Rather, it's that even if one discounted the right to privacy and freedom of expression, requiring personal-level identification would cause very serious operational issued for non-anonymous and largely non-controversial communications, in much the same way that requiring EV certificates universally would.

Indeed.  However, the decision not to address the human right of remedy (because of the difficulties outlined above,
including the potential impact to privacy and freedom of expression) is indeed balancing –  we’re consciously deciding 
"how human rights might be balanced against other design goals.” – precisely as stated in the guidelines document. 

Thanks,
/John

Disclaimer: my words alone.   Warning: scalding harzard - contents may be hot - use caution opening.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Dec 2021 08:00:00 -0800

On Sat, Dec 18, 2021 at 6:30 PM John Curran <[email-masked]> wrote:

> Indeed.  However, the decision not to address the human right of remedy
> (because of the difficulties outlined above,
> including the potential impact to privacy and freedom of expression) is
> indeed balancing –  we’re consciously deciding
> "how human rights might be balanced against other design goals.” –
> precisely as stated in the guidelines document.
>

The problem with your text is that it implies that the main balancing
factor on the other side is privacy and freedom of expression, rather than
just operational realities.

The text could probably be rephrased to address this, and if you want to do
so, I would be happy to take a look, but as-is, I think it's misleading.

-Ekr

---

From: John Curran <[email-masked]>
Date: Sun, 19 Dec 2021 11:46:24 -0500

> On 19 Dec 2021, at 11:00 AM, Eric Rescorla <[email-masked]> wrote:
> 
> On Sat, Dec 18, 2021 at 6:30 PM John Curran <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 18 Dec 2021, at 9:19 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> > ...
> The problem with your text is that it implies that the main balancing factor on the other side is privacy and freedom of expression, rather than just operational realities.
> 
> The text could probably be rephrased to address this, and if you want to do so, I would be happy to take a look, but as-is, I think it's misleading.

Eric - 

In the end, the document needs to reflect the group consensus – my text was submitted solely 
as a first draft of a potential example for the section (as requested in the Chair review), so feel 
free to revise/rephrase/replace as you deem best. 

Thanks,
/John

Disclaimer: my views alone (no one would really want them anyway…)

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 Dec 2021 17:09:14 +0100 (CET)

> Il 19/12/2021 02:43 John Curran <[email-masked]> ha scritto:
> 
Even the status quo, however, is considerably more nuanced than this. There are a number of things that you generally cannot do over the Internet without identifying yourself: for example - at least in my country - you cannot get a home Internet connection, or a SIM for your smartphone, without proving your identity with a valid document, which gets registered by the operator. You can register domain names or open email accounts without really identifying yourself, but if you then use them from your phone or your home, you do get identified in case of need (unless you use Tor etc.). We even had for many years a law that required Internet cafes to register the identities of people before giving them access to the Internet, though that's now been abolished.

Also, perhaps you can buy a domain name or a VPS without identifying yourself, as long as you can find anonymous or stolen means of payment, but the operator of those services is known, so there still is someone that law enforcement can go after, at least in terms of shutting down the illegal operation.

I may agree that for certain communication services a different balance, a bit more tilted towards personal responsibility via strong identification, could be desirable, at least if we found adequate safeguards for use cases where pseudonymity or anonymity is necessary to protect people. After all, even Facebook often asks you to prove who you are or shuts down your account. However, it's not like everything over the Internet is now anonymous.

On the other hand, it's not clear to me to which operational issues Eric refers to when he says that additional identification would be operationally hard. I can see some, but I think this really depends on the service and on the context, e.g. the jurisdiction; for example, in Italy now about half of the population has an official digital e-identity validated by the State, which anyone can get almost for free, so it would be almost trivial to require that to anyone that wants to open an email account. Then, of course, people could just go and get an email address from somewhere else on the planet.

   -- vb.

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 20 Dec 2021 17:25:07 +0100

Dear all,

I am very hesitant to add an example here because it has taken us a considerable amount of time to come to a consensus on the current text, reopening that discussion would probably not help us finalize this document.

Before the end of the year Gurshabad and I will come with a new version to seek to address the other issues brought forward by the review.

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Affiliated Faculty - Digital Democracy Institute - Simon Fraser University
Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Research Fellow - Centre for Internet and Human Rights - European University Viadrina

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 21 Dec 2021 07:42:21 -0500

Hi,

I get what you mean, Niels, but Colin is right that without an example 
we risk this section being ignored.

What about this example: Opt-in/out features like disappearing messages 
in e2ee, where a user might /not/ want this feature if they need to keep 
a record of business transactions conducted over messaging. So this 
example would help an implementer of e2ee understand that perhaps their 
protocol should allow a user to opt-out of disappearing messages, even 
if it's a highly useful privacy preserving feature.

-M

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Dec 2021 09:27:25 -0800

> if it's a highly useful privacy preserving feature.

Without taking a position on this example, I would note that generally
disappearing
messages are not really a protocol feature so much as an implementation
feature.
I.e., the message is encrypted, but once it's decrypted, the client can
retain
it indefinitely, and it's just that some clients opt not to (usually based
on a signal
from the sender).

If you want to actually prevent the receiver from retaining disappearing
messages,
you need some sort of DRM style tech.

-Ekr

-M
> > I am very hesitant to add an example here because it has taken us a
> considerable amount of time to come to a consensus on the current text,
> reopening that discussion would probably not help us finalize this document.
> >
> > Before the end of the year Gurshabad and I will come with a new version
> to seek to address the other issues brought forward by the review.
> >
> > Best,
> >
> > Niels
> >
> >> Even the status quo, however, is considerably more nuanced than this.
> There are a number of things that you generally cannot do over the Internet
> without identifying yourself: for example - at least in my country - you
> cannot get a home Internet connection, or a SIM for your smartphone,
> without proving your identity with a valid document, which gets registered
> by the operator. You can register domain names or open email accounts
> without really identifying yourself, but if you then use them from your
> phone or your home, you do get identified in case of need (unless you use
> Tor etc.). We even had for many years a law that required Internet cafes to
> register the identities of people before giving them access to the
> Internet, though that's now been abolished.
> >>
> >> Also, perhaps you can buy a domain name or a VPS without identifying
> yourself, as long as you can find anonymous or stolen means of payment, but
> the operator of those services is known, so there still is someone that law
> enforcement can go after, at least in terms of shutting down the illegal
> operation.
> >>
> >> I may agree that for certain communication services a different
> balance, a bit more tilted towards personal responsibility via strong
> identification, could be desirable, at least if we found adequate
> safeguards for use cases where pseudonymity or anonymity is necessary to
> protect people. After all, even Facebook often asks you to prove who you
> are or shuts down your account. However, it's not like everything over the
> Internet is now anonymous.
> >>
> >> On the other hand, it's not clear to me to which operational issues
> Eric refers to when he says that additional identification would be
> operationally hard. I can see some, but I think this really depends on the
> service and on the context, e.g. the jurisdiction; for example, in Italy
> now about half of the population has an official digital e-identity
> validated by the State, which anyone can get almost for free, so it would
> be almost trivial to require that to anyone that wants to open an email
> account. Then, of course, people could just go and get an email address
> from somewhere else on the planet.
> >>
> >>     -- vb.
> >>