Re: [hrpc] Status of draft-irtf-hrpc-guidelines-13

[Mallory Knodel <[e-mail]>]

Hi Colin,

Thanks for this. I want to highlight for folks more clearly the way 
forward below on the document: 
https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/

On 8/19/22 1:07 PM, Colin Perkins wrote:
> Accordingly, I’d like to ask the group to reflect on whether the guidelines and examples provided are suitable for the intended audience, and whether some more detailed examples, perhaps highlighting difference in how the various rights are interpreted in practise, might make the draft more useful.

Please in the *next two weeks,* can you weigh in with your views on 
whether and which additional examples should be included in 
draft-guidelines according to the TOC:

      4.1.  Connectivity

    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.

      4.2.  Reliability

    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.
    Similarly, an application layer protocol may require an application-
    specific acknowledgment that contains, among other things, a status
    code indicating the disposition of the request (See [RFC3724]).

      4.3.  Content agnosticism

    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.

      4.4.  Localization

    Example: The Internet is a global medium, but many of its protocols
    and products are developed with a certain audience in mind, that
    often share particular characteristics like knowing how to read and
    write in ASCII and knowing English.  This limits the ability of a
    large part of the world's online population from using the Internet
    in a way that is culturally and linguistically accessible.  An
    example of a protocol that has taken into account the view that
    individuals like to have access to data in their native language can
    be found in [RFC5646].  This protocol labels the information content
    with an identifier for the language in which it is written. And this
    allows information to be presented in more than one language.

      4.5.  Internationalization

    Example: See localization

      4.6.  Open Standards

    Example: [RFC6108] describes a system for providing critical end-user
    notifications to web browsers, which has been deployed by Comcast, an
    Internet Service Provider (ISP).  Such a notification system is being
    used to provide near-immediate notifications to customers, such as to
    warn them that their traffic exhibits patterns that are indicative of
    malware or virus infection.  There are other proprietary systems that
    can perform such notifications, but those systems utilize Deep Packet
    Inspection (DPI) technology.  In contrast, that document describes a
    system that does not rely upon DPI, and is instead based on open IETF
    standards and open source applications.

      4.7.  Heterogeneity Support

    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. Multiple
    types of application protocols must be allowed for, ranging from the
    simplest such as remote login up to the most complex such as commit
    protocols for distributed databases.  [RFC1958].

      4.8.  Integrity

    Example: Integrity verification of data is important to prevent
    vulnerabilities and attacks from on-path attackers.  These attacks
    happen when a third party (often for malicious reasons) intercepts a
    communication between two parties, inserting themselves in the middle
    changing the content of the data.  In practice this looks as follows:
    Alice wants to communicate with Bob.  Corinne forges and sends a
    message to Bob, impersonating Alice.  Bob cannot see the data from
    Alice was altered by Corinne.  Corinne intercepts and alters the
    communication as it is sent between Alice and Bob.  Corinne is able
    to control the communication content.

      4.9.  Authenticity

    Example: Authentication of data is important to prevent
    vulnerabilities, and attacks from on-path attackers.  These attacks
    happen when a third party (often for malicious reasons) intercepts a
    communication between two parties, inserting themselves in the middle
    and posing as both parties.  In practice this looks as follows:

    Alice wants to communicate with Bob.  Alice sends data to Bob.
    Corinne intercepts the data sent to Bob.  Corinne reads (and
    potentially alters) the message to Bob.  Bob cannot see the data did
    not come from Alice but from Corinne.

    When there is proper authentication the scenario would be as follows:

    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 the data did not come from Alice.

      4.10. Confidentiality

    Example: Protocols that do not encrypt their payload make the entire
    content of the communication available to the idealized attacker
    along their path.  Following the advice in [RFC3365], most such
    protocols have a secure variant that encrypts the payload for
    confidentiality, and these secure variants are seeing ever-wider
    deployment.  A noteworthy exception is DNS [RFC1035], as DNSSEC
    [RFC4033] does not have confidentiality as a requirement.  This
    implies that, in the absence of the use of more recent standards like
    DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries
    and answers generated by the activities of any protocol are available
    to the attacker.  When store-and-forward protocols are used (e.g.,
    SMTP [RFC5321]), intermediaries leave this data subject to
    observation by an attacker that has compromised these intermediaries,
    unless the data is encrypted end-to-end by the application-layer
    protocol or the implementation uses an encrypted store for this data
    [RFC7624].

      4.11. Security

    Example: See [BCP72].

      4.12. Privacy

    Example: See [RFC6973]

      4.13. Pseudonymity

    Example: Generally, pseudonymous identifiers cannot be simply reverse
    engineered.  Some early approaches took approaches such as simple
    hashing of IP addresses, but these could then be simply reversed by
    generating a hash for each potential IP address and comparing it to
    the pseudonym.

    Example: There are also efforts for application layer protocols, like
    Oblivious DNS Over HTTPS, [draft-pauly-dprive-oblivious-doh] that can
    separate identifiers from requests.

      4.14. Anonymity

    Example: An example is DHCP where sending a persistent identifier as
    the client name was not mandatory but, in practice, done by many
    implementations, before [RFC7844].

      4.15. Censorship resistance

[None]

      4.16. Outcome Transparency

    Example: Lack of authenticity may lead to lack of integrity and
    negative externalities, of which spam is an example.  Lack of data
    that could be used for billing and accounting can lead to so-called
    "free" arrangements which obscure the actual costs and distribution
    of the costs, for example the barter arrangements that are commonly
    used for Internet interconnection; and the commercial exploitation of
    personal data for targeted advertising which is the most common
    funding model for the so-called "free" services such as search
    engines and social networks.  Other unexpected outcomes might not be
    technical, but rather architectural, social or economical.

      4.17. Adaptability

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

      4.18. Accessibility

    Example: The HTML protocol as defined in [HTML5] specifically
    requires that every image must have an alt attribute (with a few
    exceptions) to ensure images are accessible for people that cannot
    themselves decipher non-text content in web pages.
    Another example is the works that is done in the AVT and AVTCORE
    working groups in the IETF that enable text conversation in
    multimedia, text telephony, wireless multimedia and video
    communications for sign language and lip-reading (ie. [RFC9071]).

      4.19. Decentralization

    Example: The bits traveling the Internet are increasingly susceptible
    to monitoring and censorship, from both governments and Internet
    service providers, as well as third (malicious) parties.  The ability
    to monitor and censor is further enabled by the increased
    centralization of the network that creates central infrastructure
    points that can be tapped into.  The creation of peer-to-peer
    networks and the development of voice-over-IP protocols using peer-
    to-peer technology in combination with distributed hash table (DHT)
    for scalability are examples of how protocols can preserve
    decentralization [Pouwelse].

      4.20. Remedy

    Example: Adding personal identifiable information to data streams
    might help in identifying a violator of human rights and provide
    access to remedy, but this would disproportionally affect all users
    right to privacy, anonymous expression, and association.

      4.21. Misc. considerations

[None]

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780