[hrpc] Late Review of draft-irtf-hrpc-guidelines-16

[Eric Rescorla <[e-mail]>]

Hi folks,

I finally got a chance to give this document a reread and have
quite a few comments. I recognize that it's inconvenient to
receive them this late in the process and I'll defer to Colin
as to how best to handle them.


FRAMING
The framing of this document centers the conduct of a "human rights
review" (Section 3) and the document talks about a Human Rights Review
Team. The implication is that there is some body (HRPC?) that stands
outside the ordinary IETF protocol design and development process and
somehow reviews protocols for their impact on human rights. It seems
to me that the available evidence is that this is not a great model,
ranging from the social (nobody likes outsiders coming in and telling
you you're doing it wrong) to practical (it fosters a shallow form of
engagement that is insufficient to address complex technical
problems.) My one experience with application of the methodology in
this document
(https://datatracker.ietf.org/doc/html/draft-martini-hrpc-quichr-00),
seemed to me to follow this pattern.

As a comparison point, I think it's useful to consider security review
and the methodology described in RFC 3552. At the time of the writing
of 3552, there was already broad consensus that Security
Considerations needed to be part of protocol development and
documentation and fairly broad agreement on how to do that analysis
(what threats should be considered, available technologies, etc.), as
well as an entity (the Security ADs) who was specifically empowered to
enforce security requirements. Despite that, there have been
persistent tensions due to differing views of what security tradeoffs
were appropriate between participants in different IETF areas. I think
experience clearly indicates that reviews of nearly finished protocols
are of limited usefulness here; what has worked much better is where
security expertise is baked into the process early, as with QUIC.

It seems to me that there are at least two reasons why protocols might
have human rights properties that are less good than we might like:

1. Protocol designers don't care as much about human rights issues
   as one might want.
2. Protocol design is a matter of compromise and so we
   end up with designs which try to balance those and so
   necessarily have suboptimal properties.

The majority of the text here seems to be devoted to justifying why
various technical features are necessary for human rights, which
implies that the problem is (1) but in my experience, (2) is much more
common. It's of course true that people have different judgements
about what's important, but in many cases it's simply a hard problem
to provide privacy, censorship resistance, etc.

To that end, I think this document should be targeted in a way that is
useful to protocol designers who are interested in human rights so
that it can be useful in the protocol development process. This
primarily means helping them identify issues and providing a path to
solutions. I don't think that's currently the case. In part, this is a
matter of adjusting the framing, but also of the content, as discussed
below.


CONTENT OVERALL
I found much of the material here very abstract and not of much use to
a working protocol designer. Let's take the discussion of anonymity
and pseudonymity in S 4.14 and S 4.15 (see more below as well.)  The
basic problem from a designer's perspective is that there are many
reasons that protocols need various kinds of identifiers and yet those
degrade privacy. So, the question is what technologies are available
to improve privacy while also providing the necessary protocol
functionality. This section is of little help in addressing that problem.

Second, much of the content in this document seems to be just about generic
properties that I think there is broad consensus protocols should
strive for (e.g., connectivity, reliability, etc.) that have been
labelled here as important for human rights. I'm not saying that that
isn't true, but in the context of this document, I don't think it's
very helpful, for three reasons:

1. As I said, these are properties that we generally aim for in
   any case, and so are likely to be covered by others.

2. The discussion here is fairly shallow and not really of much
   help in achieving these properties.

3. It distracts from the properties that are more distinctively
   about human rights and might not otherwise be considered.

IMO this document would be improved by focusing specifically on those
distinctive human rights properties and providing a much more in-depth
treatment. To return to the discussion of anonymity and pseudonymity,
it would be very useful to provide a discussion of the problem of IP
identifiers in protocols and of various ways to address the associated
privacy issues in different contexts. For instance, if you wanted to
talk about DNS, this could include material on proxying, caching, PIR,
etc.  (as well as a discussion of the tension between the privacy
afforded by caching and the tension with the recursive seeing your
query). This would be far more useful to protocol designers than
what is currently there.



DETAILED COMMENTS
S 4.1.
   Question(s): Does your protocol add application-specific functions to
   intermediary nodes?  Could this functionality be added to end nodes
   instead of intermediary nodes?

There are plenty of functions which *can* be performed at end nodes
but which are much better performed at what one might consider
intermediaries. The question is where the function is best performed.

   Is your protocol optimized for low bandwidth and high latency
   connections?  Could your protocol also be developed in a stateless
   manner?

   Explanation: The end-to-end principle [Saltzer] holds that certain
   functions can and should be performed at 'ends' of the network.
   [RFC1958] states "that in very general terms, the community believes
   that the goal is connectivity [...] and the intelligence is end to
   end rather than hidden in the network."  Generally speaking, it is
   easier to attain reliability of data transmissions with computation
   at endpoints rather than at intermediary nodes.

A few points here:

1. I don't see that the E2E principle has a lot to do with connectivity
and low bandwidth, so perhaps you need some rewrite here.

2. ISTM that the statement that opens this paragraphs is kind of
overgeneralizing the E2E argument. There are plenty of cases where
end-to-end systems are possible but behave much worse. To take one
example, P2P delivery systems have much worse reliability and
performance problems than centralized CDN-type systems.

   Example: Encrypting connections, like done with HTTPS, can add a
   significant network overhead and consequently make web resources less
   accessible to those with low bandwidth and/or high latency
   connections.  [HTTPS-REL] Encrypting traffic is a net positive for
   privacy and security, and thus protocol designers can acknowledge the
   tradeoffs of connectivity made by such decisions.

HTTPS actually does not really add significant network overhead for
most traffic. What it does--and what this citation says--is prevent
caching by intermediaries (which, incidentally, makes it an odd
example to provide in the context of this section). You should rewrite
this text. It would also be nice to provide a better reference than a
blog post, e.g., one that provided at-scale measurements and not
just anecdotes.


S 4.2.
   It is important here to draw a distinction between random degradation
   and malicious degradation.  Many current attacks against TLS
   [RFC8446], for example, exploit TLS' ability to gracefully downgrade
   to non-secure cipher suites -- from a functional perspective, this is
   useful; from a security perspective, this can be disastrous.  As with

I'm not sure what paragraph this is referring to. Are you saying that
there are a lot of current attacks on cipher suite negotiation in the
wild? If so, that seems like a surprising result, and I would expect
to see a citation to it.

Alternately, perhaps you're referring to attacks like FREAK or Logjam,
and "many current" means "a number of papers have been recently
published". If that's what you mean, then this is pretty confusing
because (1) those papers are now fairly old and (2) your citation to
TLS 1.3 which is designed to resist those attacks and (3) many
implementations removed the offending cipher suites because of this
work.

In either case, this text really needs a rewrite.


   useful; from a security perspective, this can be disastrous.  As with
   confidentiality, the growth of the Internet and fostering innovation
   in services depends on users having confidence and trust [RFC3724] in
   the network.

It's not clear to me that this is true, given that we know that the
Internet grew very quickly in a setting where there was very little
encryption (recall that HTTPS usage was well under 50% in 2014). Do
you have a citation for this claim?

   Example: In the modern IP stack structure, a reliable transport layer
   requires an indication that transport processing has successfully
   completed, such as given by TCP's ACK message [RFC0793], and not
   simply an indication from the IP layer that the packet arrived.

This is kind of an odd sentence. I mean, it's true that this is how
TCP is architected, but actually one could imagine having a system
which just acknowledged the IP packet which would probably work
almost as well. I agree that the E2E argument suggests that this
is not as good, but then that's not what this section is about.


S 4.3.

   Question(s): If your protocol impacts packet handling, does it use
   user data (packet data that is not included in the header)?  Is it
   making decisions based on the payload of the packet?  Does your
   protocol prioritize certain content or services over others in the
   routing process?  Is the protocol transparent about the
   prioritization that is made (if any)?

   Explanation: Content agnosticism refers to the notion that network
   traffic is treated identically regardless of payload, with some
   exceptions where it comes to effective traffic handling, for instance
   where it comes to delay-tolerant or delay-sensitive packets, based on
   the header.  If there is any prioritization based on the content or
   metadata of the protocol, the protocol should be transparent about
   such information and reasons thereof.


I don't think that this is a very helpful framing around content
agnosticism, for a nunmber of reasons.

1. It's possible to do traffic class discrimination based on data
   that is solely in the headers, and as more traffic is encrypted,
   increasingly this will be the main way in which people do it,
   focusing on the payload doesn't help much.

2. There are at least arguably valid reasons for providing
   differential treatment for different traffic classes. This is
   handled here in a sort of brief aside around "delay-tolerant", but
   that's of course not the only reason (e.g., DoS). I'm not as
   sympathetic to these areguments as some others, but I think they
   deserves a more thorough treatment than provided in this section.

3. In general, it's not really the *protocol* which provides
   differential treatment. It's an operational practice. The
   protocol can either enable or prevent it.


   Example: Content agnosticism prevents payload-based discrimination
   against packets.  This is important because changes to this principle
   can lead to a two-tiered Internet, where certain packets are
   prioritized over others on the basis of their content.  Effectively
   this would mean that although all users are entitled to receive their
   packets at a certain speed, some users become more equal than others.

I think it's important to distinguish between user identity and user
behavior. If, for instance, a carrier prioritizes traffic to their
own video service over some other service, it's not that they
are giving Alice more bandwidth than Bob based on their status.
This might or might not be objectionable, but it's not as simple as
"some users become more equal than others".

I suppose you could say that they are delivering their own packets
at a certain speed but not the other video service, but those
entities are not what people typically think of when they think
of "users" and of course in that case the video service is not
a customer of the carrier, so the relationships are complicated.


S 4.4.

   In the current IETF policy [RFC2277], internationalization is aimed
   at user-facing strings, not protocol elements, such as the verbs used
   by some text-based protocols.  (Do note that some strings are both
   content and protocol elements, such as identifiers.)  Given the
   IETF's mission to make the Internet a global network of networks,
   [RFC3935] developers should ensure that protocols work with languages
   apart from English and character sets apart from Latin characters.
   It is therefore crucial that at the very least, the content carried
   by the protocol can be in any script, and that all scripts are
   treated equally.

This text (and in particular "at the very least") seems to imply that
it's the opinion of this draft (and hence HRPC) that identifiers
should in fact be internationalized, but that that's not IETF
practice, but it doesn't actually say that. I don't think that that
form of I18N is a particularly good idea, but in any case, this text
should be clearer about whether it's disagreeing with that policy.


S 4.7.

   Question(s): Does your protocol support heterogeneity by design?
   Does your protocol allow for multiple types of hardware?  Does your
   protocol allow for multiple types of application protocols?  Is your
   protocol liberal in what it receives and handles?

See here:
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-10.html


   Example: Heterogeneity is inevitable and needs be supported by
   design.  Multiple types of hardware must be allowed for (e.g.,
   transmission speeds differing by at least 7 orders of magnitude,
   various computer word lengths, and hosts ranging from memory-starved
   microprocessors up to massively parallel supercomputers).

This graf seems either trivial or wrong. Yes, the Internet needs to
work over a wide range of hardware scenarios (trivial) but we
routinely design protocols that are intended to work only in
relatively modern computing environments, so the implication here that
everything we do has to work on every kind of computer is just
wrong. Indeed, that's why we see WGs/protocols that are targeted
specifically for resource-constrained environments.


S 4.8.

   Question(s): Is your protocol written in such a way that it would be
   easy for other protocols to be developed on top of it, or to interact
   with it?  Does your protocol impact permissionless innovation?  (See
   Open Standards)

This seems like it applies to a fairly narrow set of protocols
(e.g., transport protocols). For instance, what does it mean for
a new protocol to be "developed on top" of Certificate Transparency
or PKIX?


   Example: WebRTC generates audio and/or video data.  In order to
   ensure that WebRTC can be used in different locations by different
   parties, it is important that standard Javascript application
   programming interfaces (APIs) are developed to support applications
   from different voice service providers.  Multiple parties will have
   similar capabilities, in order to ensure that all parties can build
   upon existing standards these need to be adaptable, and allow for
   permissionless innovation.

I have no idea what this paragraph means. WebRTC *consists of*
standardized APIs. Are you just stating that fact? Arguing for
something new?

S 4.9/4.10.
I don't think it's that useful to talk about integrity as separate
from authentication, but if you want to, you should talk about
authentication first, as integrity isn't reall yuseful without integrity.

   Alice wants to communicate with Bob.  Alice sends data to Bob.
   Corinne intercepts the data sent to Bob.  Corinne reads and alters
   the message to Bob.  Bob can see that the data did not come from
   Alice.

This is not quite correct. What Bob can see is that he is unable
to verify that the data came from Alice, not that it did not come
from her. Consider, for instance, the case where you do a DNS
resolution and some intermediary strips the RRSIG. The data is
still authentic, just not verifiable.


S 4.11.
This section seems to conflate two different questions:

- Technical: does the protocol provide confidentiality
  (i.e., is it encrypted)

- Policy: are there mechanisms to address sharing by
  entities which can see the data

For good or bad, IETF protocols typically treat these policy questions
as out of scope. I think this section would be a lot clearer if you
focused on the technical questions.


S 4.14/S 4.15
I don't think separating out pseudonymity from anonymity is useful in
this context. For instance, it's weird to talk about ODoH in the
context of pseudonymity, when it's actually about providing anonymous
access (there's no pseudonymous identifier).

Protocols can contain identifying information that varies along at
least two axes:

- Resolution (e.g., k in k-anonymity)
- Temporal stability

At one extreme, we have complete anonymity in a system like a mixnet,
and at the other we have a system with permanent identifiers that are
scoped to a single person (e.g., something like social security
numbers). In the middle, we have a pile of different types of
identifying information with different properties, e.g.,

- IP addresses (low k, fairly stable)
- Fingerprinting (low to high k, somewhat stable)
- QUIC connection identifiers (k=1, not that stable)

Trying to cram this into a pseudonymity vs. anonymity framework
doesn't seem that useful. For instance, is a QUIC CID a pseudonym?

I would rewrite these sections something like as follows:

- Talk about the various threats and forms of leakage, including:
  identication, linkage, and reidentification

- Describe the protocol situations where some form of persistent
  identity is required and at which time scales, e.g., connection
  identifiers, user continuity identifiers, communication addresses,
  etc.

- Describe technical mechanisms for providing privacy against
  the backdrop of those protocol mechanisms. For instance:

  + TLS 1.3 encrypts the PSK identity to avoid allowing outsiders
    to link multiple connections to the same user

  + ODoH provides privacy in the face of the fact that the IP
    address (needed for communication) is identifying

  + Cookie isolation mechanisms prevent third party tracking via
    what is otherwise an identifier (the cookie)

I think this will be a lot clearer.


S 4.16
I don't think that the discussion of new user-level identifiers is that
useful in the context of censorship resistance. It's of course true
that user identifiers can be used to target people visiting certain
sites but this is more about anonymity (see above) than censorship.

   Example: Identifiers of content exposed within a protocol might be
   used to facilitate censorship, as in the case of Application Layer
   based censorship, which affects protocols like HTTP.  In HTTP, denial
   or restriction of access can be made apparent by the use of status
   code 451, which allows server operators to operate with greater
   transparency in circumstances where issues of law or public policy
   affect their operation [RFC7725].

   If a protocol potentially enables censorship, protocol designers
   should strive towards creating error codes that capture different
   scenarios (blocked due to administrative policy, unavailable because
   of legal requirements, etc.) to minimize ambiguity for end-users.

This set of paragraphs seems pretty confusing. Specifically, I don't
think it's really the case that HTTP "facilitates" censorship. HTTP is
a fairly typical client/server protocol, and the censorship in this
case consists of governments telling the servers not to serve a given
piece of content, so there's nothing specific about HTTP which really
"enables" or "facilitates" censorship (it's of course true that if
it's in the clear then censorship is easy, but 451 is designed to
operate in cases where the data is encrypted over HTTPS).

It's of course true that there are P2P protocols which are more
resistant to this kind of blocking at a particular server, but given
that they have very little deployment, it's not clear that they in
practice have better censorship properties; in fact, due to their bad
privacy properties, it's possible they have much worse properties for
targeting people who try to retrieve disfavored content.

It's a serious omission that this section doesn't talk about the
primary forms of censorship we see now, which are focused on various
kinds of blocking, either of DNS or of connections to specific
servers. You should add discussions of these techniques as well as
countermeasures such as Tor, ECH, DoH, etc.


S 4.17.
I'm really struggling with how to operationalize the guidance in this
section. Suppose that we were writing an analysis like this for (say)
SMTP, what would it say?


S 4.20.
I agree that you're identifying a useful tension here between
anonymity and addressing misbehavior, but the discussion here just
says "yeah, there's a tension", which seems unhelpful.  Do you have
any guidance for how protocols could be designed to address both of
these cases? Examples seem pretty thin on the ground, but I would at
least cite message franking as implemented in Facebook Messenger.