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

[Niels ten Oever <[e-mail]>]

It has been roughly a month since this response was posted. I want to make sure this addressed all issues and we can move forward with this draft?

Best,

Niels

On 21-02-2023 12:22, Gurshabad Grover wrote:
> Thank you for your review. v -17 of the draft is up now, which addresses your comments. Please see in-line for responses.
> 
> On 12/26/2022 10:58 PM, Eric Rescorla wrote:
>>
>> 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 <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.
>>
> 
> Section 3 aims to describe the methods of conducting a review based on the guidelines (as a work-in-progress) or in conjunction with them. The "human rights review team" is/was a small informal team that worked on applying these guidelines and improving this document. Personally, I see no implication of the text (as you point out) that there is some body "that stands outside the ordinary IETF protocol design and development process and somehow reviews protocols for their impact on human rights."
> 
> I think the document is quite clear in saying:
> 
> "Human rights reviews can be done by any participant, and can take place at different stages of the development process of an Internet-Draft. Generally speaking, it is easier to influence the development of a technology at earlier stages than at later stages. This does not mean that reviews at last-call are not relevant, but they are less likely to result in significant changes in the reviewed document."
> 
> Which to me is exactly what you are saying: that ideally, participants should be involved as early as possible in the working group.
> 
> As a separate point: While it's not possible for me here to summarise every review that has been done in the past, there are some reviews you can read in a github repo. [0] In my experience, reviews have successfully resulted in some sort of change to Internet Drafts (and have been appreciated by authors/some of the working group participants).
> 
>> 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.
>>
> 
> Thanks for framing it like this. Based on my experience in some working groups and my reading of some ietf discussions, I think that (1) and (2) co-exist. For our purposes, I don't think it matters what is more prevalent, because the document has both goals.
> 
> That is, I actually think it is quite okay to me if the document seems "devoted to justifying why various technical features are necessary for human rights", because that is one of the goals of the document and the RG.
> 
> The other goal is to provide practical guidance to reviewers/protocol designers. More on that below.
> 
>> 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.
>>
> 
> The HRPC RG does have documents dedicated to specific rights, and their aim is exactly what you describe.
> 
> In this document, while we have aimed to provide practical guidance on how to make trade-offs, some abstract guidance was inevitable because application of these principles is quite contextual. Based on your other comments (below), will try to improve the specifics.
> 
>>
>> 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.
>>
> 
> To me, the questions here are simply pointing towards the end-to-end principle. Note also the use of "application-specific" in the question.
> 
> When you say that the question is "where the function is best performed", it is not clear to me what the parameters of determining what the "best" is. Is it efficiency? Is it security?
> 
>>     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.
>>
> 
> I think the E2E principle is quite relevant to the first question under the same subheading, not to the latter. The second paragraph of the explanation relates to connectivity and low bandwidth.
> 
>> 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.
>>
> 
> Not sure what the over-generalization is, we are not talking about decentralised or end-to-end "systems" in the text you are referring to. I think the question and associated statement are about network protocols and where to place "application-specific" functions. So, in fact, it is a narrow reading of the E2E principle. For instance, one could argue that many protocols that respect the E2E principle can (and do) operate in a centralized CDN-stype environment. However (un)desirable the system itself is not something we aim to touch upon here.
> 
>>     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.
>>
> 
> The example was to say precisely that: that while caching by intermediaries may be beneficial, encrypting connections is a "net positive" because of other considerations. I've removed that reference. Here's what it reads like now, and I hope it's fine:
> 
> "Encrypting connections, like done with HTTPS, can prevent caching by intermediaries and possibly add a network overhead, making web resources less accessible to those with low bandwidth and/or high latency connections. However, encrypting traffic is a net positive for privacy and security, and thus protocol designers can acknowledge the tradeoffs of connectivity made by such decisions."
> 
>>
>> 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.
>>
> 
> Thanks, you're right, re-wrote this part.
> 
>>
>>     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?
>>
> 
> Right, that claim wasn't necessary there. Removed it.
> 
>>     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.
>>
> 
> Agreed, removed the reference to the IP packet.
> 
>>
>> 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.
>>
>>
> 
> All your points are valid. If the protocol enables traffic differentiation, the document asks for transparency for it. That's it. Slightly changed the language here based on point 3, but not sure what other changes you'd like to see.
> 
>>     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.
>>
> 
> Sure, users can be individuals, groups, or categories of users. Not sure this goes against the existing text.
> 
>>
>> 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.
>>
> 
> Thanks, simplified the language here.
> 
>>
>> 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 <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.
>>
> 
> Don't think the intention here is to document current practice, but point taken and guidance relaxed a bit.
> 
>>
>>     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?
>>
> 
> It is indeed an example. Edited the langauge for clarity.
> 
>>     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.
>>
> 
> Right, corrected.
> 
>>
>> 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.
>>
> 
> While it discusses aspects of both, I think the section is quite clear in delineating between them. For instance: "If no such mechanisms or controls are specified, is it expected that control and consent will be handled outside of the protocol?"
> 
>>
>> 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.
>>
> 
> While I'm not sure I agree with everything here, I think your comment points to the fact that pseudonymity and anonymity perhaps deserve their own detailed treatment in another I-D. I'm happy to collaborate on such an exercise. At this stage, I don't think we can make such large edits (and try to re-establish consensus in the RG).
> 
>>
>> 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).
>>
> 
> Don't think it's unfair to say that elements in the HTTP protocol "facilitate" censorship.
> 
> Not sure how your point about 451 leads to different text here, but I disagree with it in any case. RFC7725 specifically says that the "server in question [returning the 451] might not be an origin server.", because legal orders "typically most directly affects the operations of ISPs and search engines." If the requests were in plaintext, one could also an imagine an ISP intercepting the requesting and injecting a 451 response and page.
> 
>> 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.
>>
> 
> There is a reference to an ID <https://tools.ietf.org/html/draft-irtf-pearg-censorship> which describes censorship techniques in much clearer detail. We did not find it necessary to repeat that here.
> 
>>
>> 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.
>>
> 
> I think we've had multiple threads to fine-tune this text so that it represents some consensus in this RG, so I'm hesitant to change it. I disagree that it does not offer an opinion, it is saying that in the general case, adding identifiers just to provide avenues or remedy probably inconsistent with human rights (because of its effect on other rights).
> 
> I agree that citing some more examples would be useful here. I've added message franking and a recent paper on this as examples.
> 
> Thank you.
> -Gurshabad and Niels
> 
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hrpc

-- 
Niels ten Oever, PhD
Co-Principal Investigator - critical infrastructure lab - University of Amsterdam

W: https://criticalinfralab.net
W: https://nielstenoever.net
PGP: 4254 ECD5 D4CF F6AF 8B91 0D9F EFAD 2E49 CC90 C10C