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

Hi Eric, all,

Thank you for the extremely detailed review.

By my reading, your comments fall into two broad categories. Some relate 
to the overall framing and approach taken when writing this draft, and 
others focus on specific technical points that may be incorrect or are 
not well explained.

The section starting DETAILED COMMENTS contains specific technical 
questions to consider. These can be addressed without significant 
restructuring of the draft. To ensure the draft is both clear and 
correct, the authors should consider and respond to these points in 
detail on the list, and update the draft as needed.

The comments on FRAMING and CONTENT OVERALL focus more on the overall 
approach and goals of the draft. They perhaps show that there are 
differing views on the audience and expectations for the draft that 
should be considered with the goal of ensuring it has broad relevance 
and utility. I would urge the authors and RG to consider these comments, 
but understand that the group may consider it too late for a significant 
restructuring of the material.

The IRSG poll has concluded. I will mark the draft as Waiting for 
Document Shepherd and Revised I-D Needed while these comments are 
considered.

Colin

On 26 Dec 2022, at 17:28, Eric Rescorla wrote:

> 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.

> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc