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

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

Dear Eric,

Please find our response below, you can find the changes on Github: https://github.com/IRTF-HRPC/draft-guidelines - we will post it to the datatracker when I-D submission re-opens.

On 15-03-2023 03:46, Eric Rescorla wrote:
> 
> 
> On Tue, Feb 21, 2023 at 3:22 AM Gurshabad Grover <[e-mail] <mailto:[e-mail]>> 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>
>      > <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."
> 
> 
> Consider the following text:
> 
>     Methods for analyzing technology for specific human rights impacts
>     are still quite nascent.  Currently, five methods have been explored
>     by the Human Rights Review Team, often in conjunction with each
>     other:
> 
> I think this strongly suggests that there is some external body that does
> these reviews. Informal groups typically don't appear in caps.
> 

The sentence clearly refers to the team that did some reviews and helped develop the methodology. We have removed the capitals in any case.

> 
>     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.
> 
> 
> I don't really agree. TBH, the problem here is the framing of this as
> "reviews" and "influence", rather than just ordinary WG participation.
> 

It is a mode of 'ordinary' WG participation which is not in conflict with any other form of 'ordinary WG participation', which is also about reviewing document and exerting influence.

> 
>     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 sounds like we've had different experiences. BTW, this footnote does
> not seem to exist, but I don't think it's going to be that helpful to litigate
> each of these cases.

OK. The missing footnote would have led here, just in case. <https://github.com/IRTF-HRPC/reviews>


> 
>      > 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.
> 
> 
> As I said, the problem with the emphasis on (1) is that it sets up a dynamic
> of opposition in which the implication is that the WGs don't care about
> human rights and need to be lobbied by an external entity, in some
> way affiliated with the WG.
> 
> 

This is largely a subjective disagreement of what the tone of some of the text is. Some WG participants may care about human rights, some may not. There is no external entity being spoken of. Since there specific points of discussion (below), we don't think any changes are necessary because of this comment.

>      > 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?
> 
> 
> Generally efficiency, but in some cases both. The bottom line
> here is that there are strong technical reasons why we tend to
> see a lot of functions performed in intermediary nodes and
> why attempts to remove them (e.g., P2P Web systems) have
> not been successful (including cases where they actually provide
> worse security and privacy). So having text that suggests that one
> should be favoring end nodes as a matter of principle is unhelpful.

The challenge is that what happens in intermediary nodes is hard to analyze for users, and thus makes analysis of the impact harder. But if there are documented reasons why it is better to perform it in intermediary nodes, and this is documented, then the question is answered.

> 
> 
>      >     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.
> 
> 
> I don't really see the connection to the E2E principle.
> 

The end-to-end principles holds that certain functions can and should be performed at 'ends' of the network. This related to the question 'Does your protocol add application-specific functions to intermediary nodes?'.

>      > 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.
> 
> 
> The text you use here is "can and should be performed". 

That text describes the end-to-end princple.

> My point is
> that in practice there are a lot of successful systems designs that
> perform functions in intermediate nodes and struggle to do the same
> on the endpoints.

That is why it is a principle, not a law. Obviously there are cases in which it is not applicable, then it helps to document it, which should then answer the question.

> 
> 
>      >     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."
> 
> 
> This is fine.
> 

Thanks

> 
>      >
>      > 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.
> 
> 
> This text still needs some work. The "older" here needs to refer not just
> to the attacks but also the version of TLS.
> 

Changed into: "Some attacks against previous versions of TLS"

>      >
>      > 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.
> 
> 
> This text still needs work.

It would help if you would suggest what work.

> 
>     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.
> 
>     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.
> 
> Again, this confuses the properties of the protocol with the behavior
> of the network. For instance:
> 
>     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.
> 
> There are lots of protocols which don't have prioritization features but
> where prioritization is possible.
> 
> With that said, I don't in fact think that this text is good. In general,
> all our protocols have this feature because they are identifiable
> (e.g., via ALPN, port number, etc.) so this will just be boilerplate.
> 

The text describes 'payload-based discrimination', not header-based discrimination.

> 
> 
>      >     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.
> 
> 
> The problem is that the discrimination is not based on the recipient
> but rather (at most) the sender, and in some cases the traffic class.
> I don't think it's natural to think  of (say) Netflix as a "user".
> 

Also Netflix is a 'network user', at least, right?

> 
>      >
>      > 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.
> 
> 
> i don't think this fixes the problem. Again, it's not IETF practice to
> have internationalized protocol elements, and this text leaves the
> impression that this draft disagrees.
> 

The draft can disagree with current IETF practice, not sure what the intristic problem with that is.

> 
>      >
>      > 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>
>      > <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.
> 
> 
> I don't think this addresses my comments. I see you added "As far
> as possible" but I think this is much more a question of practicable
> or convenient.
> 
> 

Again, this is a principle. Trade-offs are and can be made. Even if readers take away what you describe as trivial, then we think it is fine.

> 
> 
>      >
>      > 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?"
> 
> 
> I don't really think so, but I'm willing to let this piece go.
> 

OK - thanks.

> 
>      >
>      > 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).
> 
> 
> Well, the problem is that this text is quite hard to follow.
> 

There is some treatment of the subject in RFC6973, which we directly point readers to. And you will notice that RFC6973 also has separate subsections on pseudonymity and anonymity. We're extremely grateful for the feedback, but don't think we can incorporate at this stage of the I-D.

>      > 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.
> 
> 
> I think it's unhelpful. As I said, this is a standard feature of client/server
> protocols that don't use end-to-end encryption.
> 

Why don't you think it's useful to point out that not using end-to-end encryption can mean that some protocol elements can be used to 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.
> 
> 
> I'm not saying that 451 can't be used in cases where the content
> is in the clear but that it's designed to work even if it's not.
> And given that this is in in fact the norm for HTTP now, this
> text is odd.
> 

This is simply guidance that if censorship can be made transparent with error codes. For this purpose, tt doesn't really matter that (fortunately) 451 can be used by both intermediaries and end-servers. Why is it odd?

> 
> 
>      > 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 <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.
> 
> 
> I'm not saying you should repeat it here. I'm saying you should provide
> a brief summary. Certainly in the context where you're claiming that
> HTTP facilitates censorship, it's problematic not to explain what protocol
> mechanisms would not.
> 

Thanks, included a brief summary of the main censorship techniques in draft-irtf-pearg-censorship.

> 
>      > 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 didn't say it didn't offer an opinion. Rather, what I'm saying is that
> without guidance for how to deal with misbehavior without adding
> identifiers the text isn't very helpful.
> 

I think it now points to efforts that are underway to identify abuse without sacrificing privacy. It also adequately identifies the trade-offs, and makes general guidance. As we said earlier, there have been multiple discussions to fine-tune this text and to gain RG consensus. Thank you for your comment, but any more changes to this section are likely to be counterproductive at this stage.

Thank you.

-GG and Niels