Subject: [hrpc] draft-irtf-hrpc-anonymity-00 comments

From: Nick Doty <[email-masked]>
Date: Tue, 27 Mar 2018 16:57:22 -0400

Comments on https://tools.ietf.org/html/draft-irtf-hrpc-anonymity-00 <https://tools.ietf.org/html/draft-irtf-hrpc-anonymity-00>

I hope these comments will be helpful. As I mentioned during the brief discussion in London, I'm not entirely clear on scoping this document to anonymity, when other concepts (pseudonymity, unlinkability, etc.) might often be more useful. Re-reading this again, I'm also concerned that I'm not clear on the purpose of this document and how it differs from or provides more useful guidance than existing RFC 6973.

Thanks,
Nick

Starting from the beginning:

> Anonymity is less discussed in the IETF than for instance security [RFC3552] or privacy [RFC6973].

This sentence was very confusing to me as a reader and potential reviewer. To say that anonymity is discussed less than security and privacy seems to suggest that anonymity is a concept separate from and similar in scope to security and privacy, so that they can be compared in this way. In fact (as the document will go on to note), anonymity, pseudonymity and linkability are important concepts within security and privacy and guidance around them is included as part of guidance for security and privacy considerations of Internet protocols. This seems like a misleading way to start this document.

Is the intent that this be a research document based on empirical data of how much particular properties or values topics are discussed within the IETF? That might be of interest to some of us working on quantitative analysis of RFCs and mailing list archives and perhaps we could provide data on "anonymity" as compared to other privacy and security properties. On the other hand, maybe the authors are just trying to report a general sense that anonymity and related topics are less common in protocol design discussions. I'm not sure if that's correct (linkability of identifiers is one of the main privacy topics I heard at the IETF sessions I attended last week), or what conclusions we should draw from that general sense.

> This can be attributed to the fact anonymity is a hard technical problem or that anonymizing user data is not of specific market interest. It remains a fact that 'most internet users would like to be anonymous online at least occasionally' [Pew].

>  This document aims to break down the different meanings and implications of anonymity on a mediated computer network.

Is this the current goal of the document? It seems like most of the document discusses cases where users may want anonymity or unlinkability of communications and guidance for protocol designers and implementers.

Section 1:

>    Nonetheless anonymity is not getting much discussion at the IETF,
>    providing anonymity does not seem a (semi-)objective for many
>    protocols, even though several documents contribute to improving
>    anonymity such as [RFC7258], [RFC7626], [RFC7858].

The grammar makes this difficult to parse. Is the claim that providing anonymity does not seem to be an objective for many (most?) Internet protocols? What is a semi-objective?

What is the purpose of the list of RFCs 7258, 7626 and 7858? Are these examples of protocols that do consider anonymity as one objective, despite the rarity of such protocols? (7626 and 7858 seem to fall in this category, although I'm sure we could find a much longer list.) Or are we listing documents that attempt to improve the consideration of anonymity in designing Internet protocols? (7258 would fall in that category, although presumably RFC 6973 would be even more directly relevant.)

>    There are initiatives on the Internet to improve end users anonymity, most notably [torproject], but these initiatives rely on adding
>    encryption in the application layer.

It might make more sense to say "There are initiatives to improve end users' anonymity on the Internet" rather than locating the initiatives as on the Internet.

Is there a reason that the second clause is introduced with "but"? Is there something bad about using encryption as a mechanism for promoting anonymity? Also, encryption doesn't seem to be the main way that Tor provides anonymity; the selection of multiple, random hops and the indirection of using an exit server as a proxy may have more to do with anonymity than the use of encryption. Or are we trying to introduce the idea that anonymity needs to be considered at lower layers than the application?

Finally, is it accurate to call this application layer? Tor sets up TCP streams through onion routing, and applications can work on top of it using those streams as a transport. Tor Browser seems like more directly an example of application layer. (Maybe the specific details of what counts as what layer isn't especially useful here -- I can see at least some documentation that describes onion routing as application layer and I recognize that there won't necessarily always be sharp distinctions between layers.)

Section 3:

I was surprised to read this section on PII. RFC 6973 and other privacy guidance hasn't defined PII or cited particular legal documents regarding personally identifiable information. Is the argument here that legal liability in particular jurisdictions will come into account when PII is present and so anonymity is a desirable property for system operators because it avoids the presence of PII? RFC 6973 does define "personal data" in fairly high-level terms, would that be applicable here instead?

> Anonymity will always be a balancing act between user protection
>    (which requires a high level of anonymity) and other requirments for
>    operations and research, such as routing information.

I don't think anonymity itself is a balancing act. Rather, we anticipate that the level of support for anonymity will depend on balancing user privacy and other operational requirements.

> nor has it [anonymity]
>    been a strong consideration in protocol development in the
>    development of the Internet.

I'm not sure this statement is correct. Do we want this research group document to try to show empirically that anonymity hasn't been a strong consideration in protocol development? Or if that conclusion is obvious or well-documented, could we cite some evidence?

Section 4:

I like this selection of use cases and I imagine we could expand it. In many of these cases, it seems like maybe we aren't referring specifically to anonymity within a particular anonymity set, but rather pseudoynmity, unlinkability, identity confidentiality and correlation.

Section 5:

I'm not entirely clear on how the advice in this section differs or is intended to differ from the guidance in RFC 6973, which contains particular mitigations (6. Data Minimization contains sections on anonymity, pseudonymity and identity confidentiality) and questionnaire sections on identifiers and their persistence.

Guidance for implementers does seem like a difference from RFC 6973. Do we expect implementers to read this document? If so, I could see elaborating on this section and testing it with some implementers as a useful way forward.

Section 9:

I believe the wrong email address for this group is included here. In fact, that seems to be the case for every current HRPC draft? I think we want to direct people to send comments to [email-masked] <mailto:[email-masked]>, not @ietf.org.