From nobody Tue Oct 6 17:25:40 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814D51B2D93 for ; Tue, 6 Oct 2015 17:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.124 X-Spam-Level: *** X-Spam-Status: No, score=3.124 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHATq6d5Ro76 for ; Tue, 6 Oct 2015 17:25:36 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436EC1B2D10 for ; Tue, 6 Oct 2015 17:25:35 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5198E140031 for ; Wed, 7 Oct 2015 00:25:33 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 33A31140032 for ; Wed, 7 Oct 2015 00:25:33 +0000 (UTC) Received: from [192.168.1.65] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 1A039140031 for ; Wed, 7 Oct 2015 00:25:33 +0000 (UTC) Message-ID: <5614667C.5090508@article19.org> Date: Wed, 07 Oct 2015 02:25:32 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 00:25:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, As laid out in our methodology, and discussed in Prague, we were going to document cases of in which protocols could strenghten or harm human rights (especially freedom of expression and/or freedom of assembly). We found two people ready to document cases in which protocols (potentially) strengthen or weaken human rights. Welcome on the list Will and Nex. After a discussion we decided to look into some of the following protocols: DNS [0], IP, VPN [1], HTTP, XMPP, TLS, mesh [2] and PPSPP [3]. Please find underneath the first draft by Will on DNS, all input is welcome of course. Tomorrow I will try to clean up the methodology draft as discussed and insert it in there. In the mean time all inputs, comments, questions and discussion points are very welcome! Best, Niels [0] https://www.rfc-editor.org/rfc/rfc7626.txt [1] http://www.vpnc.org/vpn-standards.html [2] https://tools.ietf.org/html/rfc2973 [3] https://www.rfc-editor.org/rfc/rfc7574.txt DNS ===== The Domain Name System (DNS), as specified in RFC 1035, acts as a core switchboard for the internet - associating human readable names with services. The DNS system operates a centralized core of ‘Root Resolvers’ , servers run by a set of organizations trusted by IANA to enact the organization’s decisions by accurately communicating which organizations have been delegated to manage registration under each Top Level Domain (TLD). Top Level domains are maintained and determined by IANA, and have evolved to encompass several classes of services. Some, like ‘.Com’ and ‘.Net’, provide a common space for expression of ideas, though their policies are enacted through US based countries. Other name spaces are delegated to specific nationalities, and may impose limits designed to focus speech in those forums both to promote speech from that nationality, and to comply with local limits on expression and social norms. Finally, the system has been recently expanded with the addition of “generic TLDs”, name spaces with accompanying regulations aimed to promote expression around specific topics, for instance ‘.travel’ and ‘.ninja’. DNS has significant privacy issues, as described in RFC 7626. Notably amongst these, the protocol does not offer either encryption to limit the visibility of requests for domain resolution from several intermediary parties, nor does it offer authentication, allowing the client to know that they have received a correct, “authoritative”, answer to a query. Together, these decisions have resulted in ongoing harm to freedom of expression as the DNS protocol has become one of the central mechanisms used to block access to websites - limiting both the freedom of expression of the publisher to offer their content, and the freedom of assembly for clients to congregate in a shared virtual space. There have been several mechanisms used impose these limitations based on the technical design of the DNS protocol. These have led to a number of situations where limits on expression have been imposed through subversion of the DNS protocol. Each of these situations has accompanying aspects of protocol design enabling those limitations. Removal of records - ----- There have been a number of cases where the records for a domain are removed from the name system due to real-world events. Examples of this removal include ‘seizure’ of names of illegally operating gambling operations by the United States ICE unit by compelling the US-based registrar in charge of the .com TLD to hand ownership of those domains over to the government. The same technique has been notably used by Libya to remove sites in violation of “our Country’s Law and Morality [which] do not allow any kind of pornography or its promotion.” At a protocol level, the ability to seize domain names is enabled by the lack of transparency into DNS transfers, or any technical encoding of name ownership. Name ownership is purely a policy decision of registrars. While DNSSEC addresses distortion events described below, it does not tackle this problem, which is has the cooperation of (or compels) the registrar. Documentation of this form of harm: [1] http://news.bbc.co.uk/2/hi/technology/7250916.stm [2] http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-libya n-government/ Distortion of records - ----- The most common mechanism by which the DNS system is abused to limit freedom of expression is through manipulation of protocol messages by the network. One form occurs at an organizational level, where client computers are instructed to use a local DNS resolver controlled by the organization. The DNS resolver will then selectively distort responses rather than request the authoritative lookup from the upstream system. The second form occurs through the use of deep packet inspection, where all DNS protocol messages are inspected by the network, and objectionable content is distorted. At the national level, there are additional considerations. The most notable is the interactions between DNS distortion and internet routing. A study on collateral damage showed that the restrictions imposed by China on DNS responses in its network also affected the availability of sites to users in Germany, since some fraction of requests would transit through the Chinese network, even though none of the participants were located there. A notable instance of distortion has occurred in Greece [3], where a study found evidence of both of deep packet inspection to distort DNS replies, and overblocking of content, where ISPs prevented clients from resolving the names of domains which they were not instructed to do through the governmental order prompting the blocking systems there. At a protocol level, the effectiveness of these attacks is made possible by a lack of authentication in the DNS protocol. The DNSSEC protocol is not widely in use, but provides an extension allowing the client to know that a response is ‘Authoritative’ - that it has been generated by the server which has technical ownership of the name requested. Even still, there are a range of downgrade attacks, where a client may continue to follow the resolution of an injected message without such a signature, since it may not know that it should expect the response to be signed. Selective distortion of records has also been made possible by the predictable structure of DNS messages, which make it computationally easy for a network device to watch all passing messages even at high speeds, and the lack of encryption, which allows the network to distort only an objectionable subset of protocol messages . Documentation of this form of harm: [1] http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf [2] http://policyreview.info/articles/analysis/internet-censorship-turke y [3] https://www.usenix.org/system/files/conference/foci15/foci15-paper-verve ris-update.pdf [4] https://tools.ietf.org/html/draft-hall-censorship-tech-01 Injection of records - ----- Responding incorrectly to requests for name lookups is the most common mechanism that in-network devices use to limit the ability of end users to discover services. A deviation which accomplishes a similar objective, though may be seen as different from a freedom of expression perspective, is the injection of incorrect responses to queries. The most prominent example of this behavior occurs in China, where requests for lookups of sites which have been deemed inappropriate will trigger the network to respond with a bogus response, causing the client to ignore the real response when it subsequently arrives. Unlike the other forms of discussion discussed above, injection does not stifle the ability of a server to announce it’s name, it instead provides another voice which answers sooner. This is effective because of the DNS protocol’s decision to provide whatever answer it receives first, and stop listening for subsequent answers, and enabled by the lack of authentication or encryption in the protocol. Documentation of this form of harm: [1] https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.p df - -- Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFGZ8AAoJEAi1oPJjbWjpMtkH/3rzGnn+HU6loxQVknIkq/0j S0HNZ5HgIVRreONRauGxgnjrquRgDoWy6dGoedcr+0OlYZCsZrQ2oHdrvlZb/tzk asF6+hYFnCyx2sOlm3qRyEjifIb2NSuQqveKAgy2ofp5bLtui5+5O/XGwH7pi/hd 8Cs/SiXCV9eMqyNehQRM2cKDb21sR1aUbvwhzPOipDkikSQHopyEv/2N0TR37h1u VYpAPuANAFHOe6vfmBLZRyPofIhEok9SypUbIcK8wYFRDszVdUBNZ/QIBRw1O330 aPbbLXPv6QbzXEVaw+JjkcTj5NLfpijP6ftw6AFzXgyejDcviC7jfDzd1HdF0Y0= =UaVp -----END PGP SIGNATURE----- From nobody Wed Oct 7 01:14:10 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A751B2B6A for ; Wed, 7 Oct 2015 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.392 X-Spam-Level: **** X-Spam-Status: No, score=4.392 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATICB=1.372, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jofjcsAPbI0O for ; Wed, 7 Oct 2015 01:14:05 -0700 (PDT) Received: from zimbra1.hivos.org (static-62-198-78-212.thenetworkfactory.nl [212.78.198.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959B21B2B68 for ; Wed, 7 Oct 2015 01:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra1.hivos.org (Postfix) with ESMTP id 48AB32CA79AC; Wed, 7 Oct 2015 10:14:01 +0200 (CEST) Received: from zimbra1.hivos.org ([127.0.0.1]) by localhost (zimbra1.hivos.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id a-VuSmbq-V_6; Wed, 7 Oct 2015 10:14:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra1.hivos.org (Postfix) with ESMTP id 23F4B2CA71A5; Wed, 7 Oct 2015 10:14:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra1.hivos.org Received: from zimbra1.hivos.org ([127.0.0.1]) by localhost (zimbra1.hivos.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QagBpEHjMIUI; Wed, 7 Oct 2015 10:14:01 +0200 (CEST) Received: from zimbra1.hivos.org (localhost [127.0.0.1]) by zimbra1.hivos.org (Postfix) with ESMTP id 01DC12CA79AC; Wed, 7 Oct 2015 10:14:01 +0200 (CEST) Date: Wed, 7 Oct 2015 10:14:00 +0200 (CEST) From: Hanane Boujemi To: Niels ten Oever Message-ID: <349959406.4679566.1444205640905.JavaMail.zimbra@hivos.org> In-Reply-To: <5614667C.5090508@article19.org> References: <5614667C.5090508@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [86.92.45.222] X-Mailer: Zimbra 8.6.0_GA_1169 (ZimbraWebClient - FF39 (Win)/8.6.0_GA_1169) Thread-Topic: cases -> DNS Thread-Index: cSLpp2Go1wMwM2MUtLey2OIezBPYhQ== Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 08:14:08 -0000 Hi Niels, I found the doc on DNS privacy consideration quite useful, do you have plan= s to produce visuals or videos which can explain in a simplified way the "p= otential" risk.. it could be useful for HR advocates? Hanane ----- Original Message ----- From: "Niels ten Oever" To: hrpc@irtf.org Sent: Wednesday, October 7, 2015 2:25:32 AM Subject: [hrpc] cases -> DNS -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, As laid out in our methodology, and discussed in Prague, we were going to document cases of in which protocols could strenghten or harm human rights (especially freedom of expression and/or freedom of assembly). We found two people ready to document cases in which protocols (potentially) strengthen or weaken human rights. Welcome on the list Will and Nex. After a discussion we decided to look into some of the following protocols: DNS [0], IP, VPN [1], HTTP, XMPP, TLS, mesh [2] and PPSPP [3]. Please find underneath the first draft by Will on DNS, all input is welcome of course. Tomorrow I will try to clean up the methodology draft as discussed and insert it in there. In the mean time all inputs, comments, questions and discussion points are very welcome! Best, Niels [0] https://www.rfc-editor.org/rfc/rfc7626.txt [1] http://www.vpnc.org/vpn-standards.html [2] https://tools.ietf.org/html/rfc2973 [3] https://www.rfc-editor.org/rfc/rfc7574.txt DNS =3D=3D=3D=3D=3D The Domain Name System (DNS), as specified in RFC 1035, acts as a core switchboard for the internet - associating human readable names with services. The DNS system operates a centralized core of =E2=80=98Root Resolvers=E2=80=99 , servers run by a set of organizations trusted by IANA = to enact the organization=E2=80=99s decisions by accurately communicating whic= h organizations have been delegated to manage registration under each Top Level Domain (TLD). Top Level domains are maintained and determined by IANA, and have evolved to encompass several classes of services. Some, like =E2=80=98.Com=E2=80=99 and =E2=80=98.Net=E2=80=99, pro= vide a common space for expression of ideas, though their policies are enacted through US based countries. Other name spaces are delegated to specific nationalities, and may impose limits designed to focus speech in those forums both to promote speech from that nationality, and to comply with local limits on expression and social norms. Finally, the system has been recently expanded with the addition of =E2=80=9Cgeneric TLDs=E2=80= =9D, name spaces with accompanying regulations aimed to promote expression around specific topics, for instance =E2=80=98.travel=E2=80=99 and =E2=80= =98.ninja=E2=80=99. DNS has significant privacy issues, as described in RFC 7626. Notably amongst these, the protocol does not offer either encryption to limit the visibility of requests for domain resolution from several intermediary parties, nor does it offer authentication, allowing the client to know that they have received a correct, =E2=80=9Cauthoritative=E2= =80=9D, answer to a query. Together, these decisions have resulted in ongoing harm to freedom of expression as the DNS protocol has become one of the central mechanisms used to block access to websites - limiting both the freedom of expression of the publisher to offer their content, and the freedom of assembly for clients to congregate in a shared virtual space. There have been several mechanisms used impose these limitations based on the technical design of the DNS protocol. These have led to a number of situations where limits on expression have been imposed through subversion of the DNS protocol. Each of these situations has accompanying aspects of protocol design enabling those limitations. Removal of records - ----- There have been a number of cases where the records for a domain are removed from the name system due to real-world events. Examples of this removal include =E2=80=98seizure=E2=80=99 of names of illegally operat= ing gambling operations by the United States ICE unit by compelling the US-based registrar in charge of the .com TLD to hand ownership of those domains over to the government. The same technique has been notably used by Libya to remove sites in violation of =E2=80=9Cour Country= =E2=80=99s Law and Morality [which] do not allow any kind of pornography or its promotion.=E2=80=9D At a protocol level, the ability to seize domain names is enabled by the lack of transparency into DNS transfers, or any technical encoding of name ownership. Name ownership is purely a policy decision of registrars. While DNSSEC addresses distortion events described below, it does not tackle this problem, which is has the cooperation of (or compels) the registrar. Documentation of this form of harm: [1] http://news.bbc.co.uk/2/hi/technology/7250916.stm [2] http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-libya n-government/ Distortion of records - ----- The most common mechanism by which the DNS system is abused to limit freedom of expression is through manipulation of protocol messages by the network. One form occurs at an organizational level, where client computers are instructed to use a local DNS resolver controlled by the organization. The DNS resolver will then selectively distort responses rather than request the authoritative lookup from the upstream system. The second form occurs through the use of deep packet inspection, where all DNS protocol messages are inspected by the network, and objectionable content is distorted. At the national level, there are additional considerations. The most notable is the interactions between DNS distortion and internet routing. A study on collateral damage showed that the restrictions imposed by China on DNS responses in its network also affected the availability of sites to users in Germany, since some fraction of requests would transit through the Chinese network, even though none of the participants were located there. A notable instance of distortion has occurred in Greece [3], where a study found evidence of both of deep packet inspection to distort DNS replies, and overblocking of content, where ISPs prevented clients from resolving the names of domains which they were not instructed to do through the governmental order prompting the blocking systems there. At a protocol level, the effectiveness of these attacks is made possible by a lack of authentication in the DNS protocol. The DNSSEC protocol is not widely in use, but provides an extension allowing the client to know that a response is =E2=80=98Authoritative=E2=80=99 - that it= has been generated by the server which has technical ownership of the name requested. Even still, there are a range of downgrade attacks, where a client may continue to follow the resolution of an injected message without such a signature, since it may not know that it should expect the response to be signed. Selective distortion of records has also been made possible by the predictable structure of DNS messages, which make it computationally easy for a network device to watch all passing messages even at high speeds, and the lack of encryption, which allows the network to distort only an objectionable subset of protocol messages . Documentation of this form of harm: [1] http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf [2] http://policyreview.info/articles/analysis/internet-censorship-turke y [3] https://www.usenix.org/system/files/conference/foci15/foci15-paper-verve ris-update.pdf [4] https://tools.ietf.org/html/draft-hall-censorship-tech-01 Injection of records - ----- Responding incorrectly to requests for name lookups is the most common mechanism that in-network devices use to limit the ability of end users to discover services. A deviation which accomplishes a similar objective, though may be seen as different from a freedom of expression perspective, is the injection of incorrect responses to queries. The most prominent example of this behavior occurs in China, where requests for lookups of sites which have been deemed inappropriate will trigger the network to respond with a bogus response, causing the client to ignore the real response when it subsequently arrives. Unlike the other forms of discussion discussed above, injection does not stifle the ability of a server to announce it=E2=80=99s name, it instead provides another voice which answers sooner. This is effective because of the DNS protocol=E2=80=99s decision to provide whatever answer it receives first, and stop listening for subsequent answers, and enabled by the lack of authentication or encryption in the protocol. Documentation of this form of harm: [1] https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.p df - --=20 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFGZ8AAoJEAi1oPJjbWjpMtkH/3rzGnn+HU6loxQVknIkq/0j S0HNZ5HgIVRreONRauGxgnjrquRgDoWy6dGoedcr+0OlYZCsZrQ2oHdrvlZb/tzk asF6+hYFnCyx2sOlm3qRyEjifIb2NSuQqveKAgy2ofp5bLtui5+5O/XGwH7pi/hd 8Cs/SiXCV9eMqyNehQRM2cKDb21sR1aUbvwhzPOipDkikSQHopyEv/2N0TR37h1u VYpAPuANAFHOe6vfmBLZRyPofIhEok9SypUbIcK8wYFRDszVdUBNZ/QIBRw1O330 aPbbLXPv6QbzXEVaw+JjkcTj5NLfpijP6ftw6AFzXgyejDcviC7jfDzd1HdF0Y0=3D =3DUaVp -----END PGP SIGNATURE----- _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc From nobody Wed Oct 7 01:27:59 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0F1B2BEE for ; Wed, 7 Oct 2015 01:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk__N-BRMZQQ for ; Wed, 7 Oct 2015 01:27:52 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A107C1B2BE9 for ; Wed, 7 Oct 2015 01:27:52 -0700 (PDT) Received: by obcgx8 with SMTP id gx8so7724363obc.3 for ; Wed, 07 Oct 2015 01:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VL9c3HNG2juNNMQaW4zAk1N3JHdJA2vKMEk6NveUs8I=; b=ncopfNeW655vgOO/njYG0yhrdMZqwgGBnlIxCq3YXQsI45/54/TwKc/uNDo60NFrc2 nuSXBKe/lYW05p/ZXeo4U9xPrvEM5DBcjP3yMVJUB/zJSaM/HM5eKzQm3w5/PAf9FPEy AuCMti0Y6hqWtSxHGILc0Qhcg7ImqUua04IzYTBjGukYQjFfp5MScQ2BnaCxH++nFxso aqE+QlA8par5Eq7dxPZ3Q/4Pr1DCeK3E8gOgyJvIOMzePpZULeaD6EIR8gZciaom/qbj 8yZEHshTJlXYKHGLbbJMVQaVkTVN+u/vSXGUZZucprv44AHV9PklDQ1vw8sNDu8+PtBH bd+w== X-Received: by 10.182.104.130 with SMTP id ge2mr23161722obb.79.1444206471838; Wed, 07 Oct 2015 01:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.14.228 with HTTP; Wed, 7 Oct 2015 01:27:32 -0700 (PDT) In-Reply-To: <349959406.4679566.1444205640905.JavaMail.zimbra@hivos.org> References: <5614667C.5090508@article19.org> <349959406.4679566.1444205640905.JavaMail.zimbra@hivos.org> From: Rafik Dammak Date: Wed, 7 Oct 2015 17:27:32 +0900 Message-ID: To: Hanane Boujemi Content-Type: multipart/alternative; boundary=089e0112cf10bc85ac05217f852f Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 08:27:57 -0000 --089e0112cf10bc85ac05217f852f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hanane, AFNIC usually published some easy-to read document about DNS for public https://www.afnic.fr/medias/documents/afnic-dns-attacks-security-guide-2009= -06.pdf . maybe not necessarily targeting activists . maybe other registry operators and DNS providers have such material too. Best, Rafik 2015-10-07 17:14 GMT+09:00 Hanane Boujemi : > Hi Niels, > > I found the doc on DNS privacy consideration quite useful, do you have > plans to produce visuals or videos which can explain in a simplified way > the "potential" risk.. it could be useful for HR advocates? > > Hanane > > ----- Original Message ----- > From: "Niels ten Oever" > To: hrpc@irtf.org > Sent: Wednesday, October 7, 2015 2:25:32 AM > Subject: [hrpc] cases -> DNS > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi all, > > As laid out in our methodology, and discussed in Prague, we were going > to document cases of in which protocols could strenghten or harm human > rights (especially freedom of expression and/or freedom of assembly). > We found two people ready to document cases in which protocols > (potentially) strengthen or weaken human rights. Welcome on the list > Will and Nex. After a discussion we decided to look into some of the > following protocols: DNS [0], IP, VPN [1], HTTP, XMPP, TLS, mesh [2] > and PPSPP [3]. > > Please find underneath the first draft by Will on DNS, all input is > welcome of course. Tomorrow I will try to clean up the methodology > draft as discussed and insert it in there. In the mean time all > inputs, comments, questions and discussion points are very welcome! > > Best, > > Niels > > [0] https://www.rfc-editor.org/rfc/rfc7626.txt > [1] http://www.vpnc.org/vpn-standards.html > [2] https://tools.ietf.org/html/rfc2973 > [3] https://www.rfc-editor.org/rfc/rfc7574.txt > > DNS > =3D=3D=3D=3D=3D > > The Domain Name System (DNS), as specified in RFC 1035, acts as a core > switchboard for the internet - associating human readable names with > services. The DNS system operates a centralized core of =E2=80=98Root > Resolvers=E2=80=99 , servers run by a set of organizations trusted by IAN= A to > enact the organization=E2=80=99s decisions by accurately communicating wh= ich > organizations have been delegated to manage registration under each > Top Level Domain (TLD). Top Level domains are maintained and > determined by IANA, and have evolved to encompass several classes of > services. Some, like =E2=80=98.Com=E2=80=99 and =E2=80=98.Net=E2=80=99, p= rovide a common space for > expression of ideas, though their policies are enacted through US > based countries. Other name spaces are delegated to specific > nationalities, and may impose limits designed to focus speech in those > forums both to promote speech from that nationality, and to comply > with local limits on expression and social norms. Finally, the system > has been recently expanded with the addition of =E2=80=9Cgeneric TLDs=E2= =80=9D, name > spaces with accompanying regulations aimed to promote expression > around specific topics, for instance =E2=80=98.travel=E2=80=99 and =E2=80= =98.ninja=E2=80=99. > > DNS has significant privacy issues, as described in RFC 7626. Notably > amongst these, the protocol does not offer either encryption to limit > the visibility of requests for domain resolution from several > intermediary parties, nor does it offer authentication, allowing the > client to know that they have received a correct, =E2=80=9Cauthoritative= =E2=80=9D, > answer to a query. Together, these decisions have resulted in ongoing > harm to freedom of expression as the DNS protocol has become one of > the central mechanisms used to block access to websites - limiting > both the freedom of expression of the publisher to offer their > content, and the freedom of assembly for clients to congregate in a > shared virtual space. > > There have been several mechanisms used impose these limitations based > on the technical design of the DNS protocol. These have led to a > number of situations where limits on expression have been imposed > through subversion of the DNS protocol. Each of these situations has > accompanying aspects of protocol design enabling those limitations. > > Removal of records > - ----- > There have been a number of cases where the records for a domain are > removed from the name system due to real-world events. Examples of > this removal include =E2=80=98seizure=E2=80=99 of names of illegally oper= ating > gambling operations by the United States ICE unit by compelling the > US-based registrar in charge of the .com TLD to hand ownership of > those domains over to the government. The same technique has been > notably used by Libya to remove sites in violation of =E2=80=9Cour Countr= y=E2=80=99s > Law and Morality [which] do not allow any kind of pornography or its > promotion.=E2=80=9D > > At a protocol level, the ability to seize domain names is enabled by > the lack of transparency into DNS transfers, or any technical encoding > of name ownership. Name ownership is purely a policy decision of > registrars. While DNSSEC addresses distortion events described below, > it does not tackle this problem, which is has the cooperation of (or > compels) the registrar. > > Documentation of this form of harm: > [1] http://news.bbc.co.uk/2/hi/technology/7250916.stm > [2] > http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-libya > n-government/ > > Distortion of records > - ----- > The most common mechanism by which the DNS system is abused to limit > freedom of expression is through manipulation of protocol messages by > the network. One form occurs at an organizational level, where client > computers are instructed to use a local DNS resolver controlled by the > organization. The DNS resolver will then selectively distort responses > rather than request the authoritative lookup from the upstream system. > The second form occurs through the use of deep packet inspection, > where all DNS protocol messages are inspected by the network, and > objectionable content is distorted. > > At the national level, there are additional considerations. The most > notable is the interactions between DNS distortion and internet > routing. A study on collateral damage showed that the restrictions > imposed by China on DNS responses in its network also affected the > availability of sites to users in Germany, since some fraction of > requests would transit through the Chinese network, even though none > of the participants were located there. > > A notable instance of distortion has occurred in Greece [3], where a > study found evidence of both of deep packet inspection to distort DNS > replies, and overblocking of content, where ISPs prevented clients > from resolving the names of domains which they were not instructed to > do through the governmental order prompting the blocking systems there. > > At a protocol level, the effectiveness of these attacks is made > possible by a lack of authentication in the DNS protocol. The DNSSEC > protocol is not widely in use, but provides an extension allowing the > client to know that a response is =E2=80=98Authoritative=E2=80=99 - that = it has been > generated by the server which has technical ownership of the name > requested. Even still, there are a range of downgrade attacks, where a > client may continue to follow the resolution of an injected message > without such a signature, since it may not know that it should expect > the response to be signed. Selective distortion of records has also > been made possible by the predictable structure of DNS messages, which > make it computationally easy for a network device to watch all passing > messages even at high speeds, and the lack of encryption, which allows > the network to distort only an objectionable subset of protocol messages > . > > Documentation of this form of harm: > [1] http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf > [2] http://policyreview.info/articles/analysis/internet-censorship-turke > y > [3] > https://www.usenix.org/system/files/conference/foci15/foci15-paper-verve > ris-update.pdf > [4] https://tools.ietf.org/html/draft-hall-censorship-tech-01 > > Injection of records > - ----- > Responding incorrectly to requests for name lookups is the most common > mechanism that in-network devices use to limit the ability of end > users to discover services. A deviation which accomplishes a similar > objective, though may be seen as different from a freedom of > expression perspective, is the injection of incorrect responses to > queries. The most prominent example of this behavior occurs in China, > where requests for lookups of sites which have been deemed > inappropriate will trigger the network to respond with a bogus > response, causing the client to ignore the real response when it > subsequently arrives. Unlike the other forms of discussion discussed > above, injection does not stifle the ability of a server to announce > it=E2=80=99s name, it instead provides another voice which answers sooner= . > This is effective because of the DNS protocol=E2=80=99s decision to provi= de > whatever answer it receives first, and stop listening for subsequent > answers, and enabled by the lack of authentication or encryption in > the protocol. > > Documentation of this form of harm: > [1] > https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.p > df > > > - -- > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWFGZ8AAoJEAi1oPJjbWjpMtkH/3rzGnn+HU6loxQVknIkq/0j > S0HNZ5HgIVRreONRauGxgnjrquRgDoWy6dGoedcr+0OlYZCsZrQ2oHdrvlZb/tzk > asF6+hYFnCyx2sOlm3qRyEjifIb2NSuQqveKAgy2ofp5bLtui5+5O/XGwH7pi/hd > 8Cs/SiXCV9eMqyNehQRM2cKDb21sR1aUbvwhzPOipDkikSQHopyEv/2N0TR37h1u > VYpAPuANAFHOe6vfmBLZRyPofIhEok9SypUbIcK8wYFRDszVdUBNZ/QIBRw1O330 > aPbbLXPv6QbzXEVaw+JjkcTj5NLfpijP6ftw6AFzXgyejDcviC7jfDzd1HdF0Y0=3D > =3DUaVp > -----END PGP SIGNATURE----- > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --089e0112cf10bc85ac05217f852f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hanane,

AFNIC usually published so= me easy-to read document about DNS for public=C2=A0http= s://www.afnic.fr/medias/documents/afnic-dns-attacks-security-guide-2009-06.= pdf . maybe not necessarily targeting activists .
maybe other registry operators and DNS providers have such material too.

Best,

Rafik

2015-10-07 17:= 14 GMT+09:00 Hanane Boujemi <hboujemi@hivos.org>:
Hi Niels,

I found the doc on DNS privacy consideration quite useful, do you have plan= s to produce visuals or videos which can explain in a simplified way the &q= uot;potential" risk.. it could be useful for HR advocates?

Hanane

----- Original Message -----
From: "Niels ten Oever" <niels@article19.org>
To: hrpc@irtf.org
Sent: Wednesday, October 7, 2015 2:25:32 AM
Subject: [hrpc] cases -> DNS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

As laid out in our methodology, and discussed in Prague, we were going
to document cases of in which protocols could strenghten or harm human
rights (especially freedom of expression and/or freedom of assembly).
We found two people ready to document cases in which protocols
(potentially) strengthen or weaken human rights. Welcome on the list
Will and Nex. After a discussion we decided to look into some of the
following protocols: DNS [0], IP, VPN [1], HTTP, XMPP, TLS, mesh [2]
and PPSPP [3].

Please find underneath the first draft by Will on DNS, all input is
welcome of course. Tomorrow I will try to clean up the methodology
draft as discussed and insert it in there. In the mean time all
inputs, comments, questions and discussion points are very welcome!

Best,

Niels

[0] https://www.rfc-editor.org/rfc/rfc7626.txt
[1] http://www.vpnc.org/vpn-standards.html
[2] https://tools.ietf.org/html/rfc2973
[3] https://www.rfc-editor.org/rfc/rfc7574.txt

DNS
=3D=3D=3D=3D=3D

The Domain Name System (DNS), as specified in RFC 1035, acts as a core
switchboard for the internet - associating human readable names with
services. The DNS system operates a centralized core of =E2=80=98Root
Resolvers=E2=80=99 , servers run by a set of organizations trusted by IANA = to
enact the organization=E2=80=99s decisions by accurately communicating whic= h
organizations have been delegated to manage registration under each
Top Level Domain (TLD). Top Level domains are maintained and
determined by IANA, and have evolved to encompass several classes of
services. Some, like =E2=80=98.Com=E2=80=99 and =E2=80=98.Net=E2=80=99, pro= vide a common space for
expression of ideas, though their policies are enacted through US
based countries. Other name spaces are delegated to specific
nationalities, and may impose limits designed to focus speech in those
forums both to promote speech from that nationality, and to comply
with local limits on expression and social norms. Finally, the system
has been recently expanded with the addition of =E2=80=9Cgeneric TLDs=E2=80= =9D, name
spaces with accompanying regulations aimed to promote expression
around specific topics, for instance =E2=80=98.travel=E2=80=99 and =E2=80= =98.ninja=E2=80=99.

DNS has significant privacy issues, as described in RFC 7626. Notably
amongst these, the protocol does not offer either encryption to limit
the visibility of requests for domain resolution from several
intermediary parties, nor does it offer authentication, allowing the
client to know that they have received a correct, =E2=80=9Cauthoritative=E2= =80=9D,
answer to a query. Together, these decisions have resulted in ongoing
harm to freedom of expression as the DNS protocol has become one of
the central mechanisms used to block access to websites - limiting
both the freedom of expression of the publisher to offer their
content, and the freedom of assembly for clients to congregate in a
shared virtual space.

There have been several mechanisms used impose these limitations based
on the technical design of the DNS protocol. These have led to a
number of situations where limits on expression have been imposed
through subversion of the DNS protocol. Each of these situations has
accompanying aspects of protocol design enabling those limitations.

Removal of records
- -----
There have been a number of cases where the records for a domain are
removed from the name system due to real-world events. Examples of
this removal include =E2=80=98seizure=E2=80=99 of names of illegally operat= ing
gambling operations by the United States ICE unit by compelling the
US-based registrar in charge of the .com TLD to hand ownership of
those domains over to the government. The same technique has been
notably used by Libya to remove sites in violation of =E2=80=9Cour Country= =E2=80=99s
Law and Morality [which] do not allow any kind of pornography or its
promotion.=E2=80=9D

At a protocol level, the ability to seize domain names is enabled by
the lack of transparency into DNS transfers, or any technical encoding
of name ownership. Name ownership is purely a policy decision of
registrars. While DNSSEC addresses distortion events described below,
it does not tackle this problem, which is has the cooperation of (or
compels) the registrar.

Documentation of this form of harm:
[1] http://news.bbc.co.uk/2/hi/technology/7250916.s= tm
[2]
http://techyum.com/2010= /10/official-vb-ly-link-shortener-seized-by-libya
n-government/

Distortion of records
- -----
The most common mechanism by which the DNS system is abused to limit
freedom of expression is through manipulation of protocol messages by
the network. One form occurs at an organizational level, where client
computers are instructed to use a local DNS resolver controlled by the
organization. The DNS resolver will then selectively distort responses
rather than request the authoritative lookup from the upstream system.
The second form occurs through the use of deep packet inspection,
where all DNS protocol messages are inspected by the network, and
objectionable content is distorted.

At the national level, there are additional considerations. The most
notable is the interactions between DNS distortion and internet
routing. A study on collateral damage showed that the restrictions
imposed by China on DNS responses in its network also affected the
availability of sites to users in Germany, since some fraction of
requests would transit through the Chinese network, even though none
of the participants were located there.

A notable instance of distortion has occurred in Greece [3], where a
study found evidence of both of deep packet inspection to distort DNS
replies, and overblocking of content, where ISPs prevented clients
from resolving the names of domains which they were not instructed to
do through the governmental order prompting the blocking systems there.

At a protocol level, the effectiveness of these attacks is made
possible by a lack of authentication in the DNS protocol. The DNSSEC
protocol is not widely in use, but provides an extension allowing the
client to know that a response is =E2=80=98Authoritative=E2=80=99 - that it= has been
generated by the server which has technical ownership of the name
requested. Even still, there are a range of downgrade attacks, where a
client may continue to follow the resolution of an injected message
without such a signature, since it may not know that it should expect
the response to be signed. Selective distortion of records has also
been made possible by the predictable structure of DNS messages, which
make it computationally easy for a network device to watch all passing
messages even at high speeds, and the lack of encryption, which allows
the network to distort only an objectionable subset of protocol messages .

Documentation of this form of harm:
[1] http://conferences.sigcomm.org= /sigcomm/2012/paper/ccr-paper266.pdf
[2] http://policyreview.info/art= icles/analysis/internet-censorship-turke
y
[3]
https://www.usenix.org= /system/files/conference/foci15/foci15-paper-verve
ris-update.pdf
[4] https://tools.ietf.org/html/draft-hall-= censorship-tech-01

Injection of records
- -----
Responding incorrectly to requests for name lookups is the most common
mechanism that in-network devices use to limit the ability of end
users to discover services. A deviation which accomplishes a similar
objective, though may be seen as different from a freedom of
expression perspective, is the injection of incorrect responses to
queries.=C2=A0 The most prominent example of this behavior occurs in China,=
where requests for lookups of sites which have been deemed
inappropriate will trigger the network to respond with a bogus
response, causing the client to ignore the real response when it
subsequently arrives. Unlike the other forms of discussion discussed
above, injection does not stifle the ability of a server to announce
it=E2=80=99s name, it instead provides another voice which answers sooner.<= br> This is effective because of the DNS protocol=E2=80=99s decision to provide=
whatever answer it receives first, and stop listening for subsequent
answers, and enabled by the lack of authentication or encryption in
the protocol.

Documentation of this form of harm:
[1]
https://www.usenix.org/system/file= s/conference/foci14/foci14-anonymous.p
df


- --
Niels ten Oever
Head of Digital

Article 19
w= ww.article19.org

PGP fingerprint=C2=A0 =C2=A0 8D9F C567 BEE4 A431 56C4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0678B 0= 8B5 A0F2 636D 68E9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWFGZ8AAoJEAi1oPJjbWjpMtkH/3rzGnn+HU6loxQVknIkq/0j
S0HNZ5HgIVRreONRauGxgnjrquRgDoWy6dGoedcr+0OlYZCsZrQ2oHdrvlZb/tzk
asF6+hYFnCyx2sOlm3qRyEjifIb2NSuQqveKAgy2ofp5bLtui5+5O/XGwH7pi/hd
8Cs/SiXCV9eMqyNehQRM2cKDb21sR1aUbvwhzPOipDkikSQHopyEv/2N0TR37h1u
VYpAPuANAFHOe6vfmBLZRyPofIhEok9SypUbIcK8wYFRDszVdUBNZ/QIBRw1O330
aPbbLXPv6QbzXEVaw+JjkcTj5NLfpijP6ftw6AFzXgyejDcviC7jfDzd1HdF0Y0=3D
=3DUaVp
-----END PGP SIGNATURE-----

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

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

--089e0112cf10bc85ac05217f852f-- From nobody Wed Oct 7 02:25:49 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0A71B2CAA for ; Wed, 7 Oct 2015 02:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbBLaRCh4XQy for ; Wed, 7 Oct 2015 02:25:44 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3161B2CAD for ; Wed, 7 Oct 2015 02:25:44 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 648CE81C6; Wed, 7 Oct 2015 09:25:42 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 4937D81C7; Wed, 7 Oct 2015 09:25:42 +0000 (UTC) Received: from [192.168.43.18] (unknown [62.72.193.111]) by mail.article19.io (Postfix) with ESMTPSA id 13B7B81C6; Wed, 7 Oct 2015 09:25:42 +0000 (UTC) Message-ID: <5614E514.3080403@article19.org> Date: Wed, 07 Oct 2015 11:25:40 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Hanane Boujemi References: <5614667C.5090508@article19.org> <349959406.4679566.1444205640905.JavaMail.zimbra@hivos.org> In-Reply-To: <349959406.4679566.1444205640905.JavaMail.zimbra@hivos.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 09:25:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Hanane, We're currently producing a film on the relation between Internet protocols and Internet rights which will premiere at IETF94 in Yokohama, and after that will be available online. The film is based largely on interviews we did with the IETF community at IETF92 in Dallas, but we're creating animations and adding other content to make it a bit more attractive and digestible right now. Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 10/07/2015 10:14 AM, Hanane Boujemi wrote: > Hi Niels, > > I found the doc on DNS privacy consideration quite useful, do you > have plans to produce visuals or videos which can explain in a > simplified way the "potential" risk.. it could be useful for HR > advocates? > > Hanane > > ----- Original Message ----- From: "Niels ten Oever" > To: hrpc@irtf.org Sent: Wednesday, October 7, > 2015 2:25:32 AM Subject: [hrpc] cases -> DNS > > Hi all, > > As laid out in our methodology, and discussed in Prague, we were > going to document cases of in which protocols could strenghten or > harm human rights (especially freedom of expression and/or freedom > of assembly). We found two people ready to document cases in which > protocols (potentially) strengthen or weaken human rights. Welcome > on the list Will and Nex. After a discussion we decided to look > into some of the following protocols: DNS [0], IP, VPN [1], HTTP, > XMPP, TLS, mesh [2] and PPSPP [3]. > > Please find underneath the first draft by Will on DNS, all input > is welcome of course. Tomorrow I will try to clean up the > methodology draft as discussed and insert it in there. In the mean > time all inputs, comments, questions and discussion points are very > welcome! > > Best, > > Niels > > [0] https://www.rfc-editor.org/rfc/rfc7626.txt [1] > http://www.vpnc.org/vpn-standards.html [2] > https://tools.ietf.org/html/rfc2973 [3] > https://www.rfc-editor.org/rfc/rfc7574.txt > > DNS ===== > > The Domain Name System (DNS), as specified in RFC 1035, acts as a > core switchboard for the internet - associating human readable > names with services. The DNS system operates a centralized core of > ‘Root Resolvers’ , servers run by a set of organizations trusted by > IANA to enact the organization’s decisions by accurately > communicating which organizations have been delegated to manage > registration under each Top Level Domain (TLD). Top Level domains > are maintained and determined by IANA, and have evolved to > encompass several classes of services. Some, like ‘.Com’ and > ‘.Net’, provide a common space for expression of ideas, though > their policies are enacted through US based countries. Other name > spaces are delegated to specific nationalities, and may impose > limits designed to focus speech in those forums both to promote > speech from that nationality, and to comply with local limits on > expression and social norms. Finally, the system has been recently > expanded with the addition of “generic TLDs”, name spaces with > accompanying regulations aimed to promote expression around > specific topics, for instance ‘.travel’ and ‘.ninja’. > > DNS has significant privacy issues, as described in RFC 7626. > Notably amongst these, the protocol does not offer either > encryption to limit the visibility of requests for domain > resolution from several intermediary parties, nor does it offer > authentication, allowing the client to know that they have received > a correct, “authoritative”, answer to a query. Together, these > decisions have resulted in ongoing harm to freedom of expression as > the DNS protocol has become one of the central mechanisms used to > block access to websites - limiting both the freedom of expression > of the publisher to offer their content, and the freedom of > assembly for clients to congregate in a shared virtual space. > > There have been several mechanisms used impose these limitations > based on the technical design of the DNS protocol. These have led > to a number of situations where limits on expression have been > imposed through subversion of the DNS protocol. Each of these > situations has accompanying aspects of protocol design enabling > those limitations. > > Removal of records ----- There have been a number of cases where > the records for a domain are removed from the name system due to > real-world events. Examples of this removal include ‘seizure’ of > names of illegally operating gambling operations by the United > States ICE unit by compelling the US-based registrar in charge of > the .com TLD to hand ownership of those domains over to the > government. The same technique has been notably used by Libya to > remove sites in violation of “our Country’s Law and Morality > [which] do not allow any kind of pornography or its promotion.” > > At a protocol level, the ability to seize domain names is enabled > by the lack of transparency into DNS transfers, or any technical > encoding of name ownership. Name ownership is purely a policy > decision of registrars. While DNSSEC addresses distortion events > described below, it does not tackle this problem, which is has the > cooperation of (or compels) the registrar. > > Documentation of this form of harm: [1] > http://news.bbc.co.uk/2/hi/technology/7250916.stm [2] > http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-lib ya > > n-government/ > > Distortion of records ----- The most common mechanism by which the > DNS system is abused to limit freedom of expression is through > manipulation of protocol messages by the network. One form occurs > at an organizational level, where client computers are instructed > to use a local DNS resolver controlled by the organization. The DNS > resolver will then selectively distort responses rather than > request the authoritative lookup from the upstream system. The > second form occurs through the use of deep packet inspection, where > all DNS protocol messages are inspected by the network, and > objectionable content is distorted. > > At the national level, there are additional considerations. The > most notable is the interactions between DNS distortion and > internet routing. A study on collateral damage showed that the > restrictions imposed by China on DNS responses in its network also > affected the availability of sites to users in Germany, since some > fraction of requests would transit through the Chinese network, > even though none of the participants were located there. > > A notable instance of distortion has occurred in Greece [3], where > a study found evidence of both of deep packet inspection to distort > DNS replies, and overblocking of content, where ISPs prevented > clients from resolving the names of domains which they were not > instructed to do through the governmental order prompting the > blocking systems there. > > At a protocol level, the effectiveness of these attacks is made > possible by a lack of authentication in the DNS protocol. The > DNSSEC protocol is not widely in use, but provides an extension > allowing the client to know that a response is ‘Authoritative’ - > that it has been generated by the server which has technical > ownership of the name requested. Even still, there are a range of > downgrade attacks, where a client may continue to follow the > resolution of an injected message without such a signature, since > it may not know that it should expect the response to be signed. > Selective distortion of records has also been made possible by the > predictable structure of DNS messages, which make it > computationally easy for a network device to watch all passing > messages even at high speeds, and the lack of encryption, which > allows the network to distort only an objectionable subset of > protocol messages . > > Documentation of this form of harm: [1] > http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf > [2] > http://policyreview.info/articles/analysis/internet-censorship-turke > > y > [3] > https://www.usenix.org/system/files/conference/foci15/foci15-paper-ver ve > > ris-update.pdf > [4] https://tools.ietf.org/html/draft-hall-censorship-tech-01 > > Injection of records ----- Responding incorrectly to requests for > name lookups is the most common mechanism that in-network devices > use to limit the ability of end users to discover services. A > deviation which accomplishes a similar objective, though may be > seen as different from a freedom of expression perspective, is the > injection of incorrect responses to queries. The most prominent > example of this behavior occurs in China, where requests for > lookups of sites which have been deemed inappropriate will trigger > the network to respond with a bogus response, causing the client to > ignore the real response when it subsequently arrives. Unlike the > other forms of discussion discussed above, injection does not > stifle the ability of a server to announce it’s name, it instead > provides another voice which answers sooner. This is effective > because of the DNS protocol’s decision to provide whatever answer > it receives first, and stop listening for subsequent answers, and > enabled by the lack of authentication or encryption in the > protocol. > > Documentation of this form of harm: [1] > https://www.usenix.org/system/files/conference/foci14/foci14-anonymous .p > > df > > > > _______________________________________________ hrpc mailing list > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFOUUAAoJEAi1oPJjbWjpatMH/A7ThERTQTgb0WF4qHJ37r+c 5FeYQJW3r7ZTFQgxmXRH2HI2o3d5pQZtE78eBYaUjrtm6Jd4YWfIHZfgIM4pTaUZ wMuimU30eeyZWj9r4tC43+cshMHq6UfNyZl7PdRB/u/ajIKEcg4satm+O7kN2nzf inFObkPAfMT3gnjwaRlMxUp8/zaeJQ9dyv3oQmAERG2UoAWcgYuM8tennh67orsa wIqYkwyqlioiBc8qcnqbXZBbkh8KpMtSgznfb9PcSYWdEjR78O68MU+TWRJQpNph QDmaaZkC70iKTO1cB65x/tex0ks54Dda3oWqFYsLB1MRUkXbEtsTfMhjel+mTrs= =UXJd -----END PGP SIGNATURE----- From nobody Wed Oct 7 03:02:29 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5C31B2D2B for ; Wed, 7 Oct 2015 03:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx5CLABmTVmr for ; Wed, 7 Oct 2015 03:02:26 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462D31B2D2A for ; Wed, 7 Oct 2015 03:02:26 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E5D9F2800F2; Wed, 7 Oct 2015 12:02:23 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id E0FE728002B; Wed, 7 Oct 2015 12:02:23 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id DE9F94C004D; Wed, 7 Oct 2015 12:01:53 +0200 (CEST) Date: Wed, 7 Oct 2015 12:01:53 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151007100153.GB20416@nic.fr> References: <5614667C.5090508@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5614667C.5090508@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 10:02:28 -0000 > Please find underneath the first draft by Will on DNS, > The DNS system operates a centralized core of ‘Root Resolvers’ , Please pay attention to the terminology. There is no such thing as a root resolver. This was probably a reference to root servers. Also, the adjective "centralized" seems strange here. > servers run by a set of organizations trusted by IANA Precisely not (this is one of the darkest secrets of Intenet governance). The root server operators existed long before ICANN, the vast majority of them have zero relationshiop with ICANN and there is no ICANN process to add or remove a root server. > Top Level domains are maintained and determined by IANA, Add "acting as a delegate of the US governement" > nor does it offer authentication, allowing the client to know that > they have received a correct, “authoritative”, answer to a query. This is untrue, because of DNSSEC (which is mentioned later but ignored in this sentence). > the US-based registrar in charge of the .com TLD Registry not registrar. > At a protocol level, the ability to seize domain names is enabled by > the lack of transparency into DNS transfers, I do not see what is the "lack of transparency into DNS transfers". > or any technical encoding of name ownership. Is it a reference to alternative techniques like proving name ownership through cryptographic signatures plus a public record, such as Namecoin? If so, it could be explained more clearly. > At a protocol level, the effectiveness of these attacks is made > possible by a lack of authentication in the DNS protocol. The DNSSEC > protocol is not widely in use, but provides an extension allowing > the client to know that a response is ‘Authoritative’ - that it has > been generated by the server which has technical ownership of the > name requested. Self contradictory sentence: either DNSSEC exists or it doesn't. If it exists (which is the case), there *is* "authentication in the DNS protocol". > Even still, there are a range of downgrade attacks, where a client > may continue to follow the resolution of an injected message without > such a signature, since it may not know that it should expect the > response to be signed. Either there is a technical weakness in DNSSEC, allowing this attack, and it must be published, to allow IETF to patch the DNSSEC protocol (or to drop it), or this is pure FUD (I have no idea of where does this sentence come from). Technical note: the DNS client knows that "it should expect the response to be signed" through the DS (Delegation Signed) records. When there is really no DS, the client knows it through "secure denial of existence", thanks to NSEC and NSEC records. From nobody Wed Oct 7 03:53:48 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A25A1B2DBF for ; Wed, 7 Oct 2015 03:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06Tp3PSzMpo9 for ; Wed, 7 Oct 2015 03:53:44 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467A91B2CFE for ; Wed, 7 Oct 2015 03:53:43 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 0B7B181C7; Wed, 7 Oct 2015 10:53:42 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id EF45881C9; Wed, 7 Oct 2015 10:53:41 +0000 (UTC) Received: from [192.168.1.65] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id D6C3E81C7; Wed, 7 Oct 2015 10:53:41 +0000 (UTC) Message-ID: <5614F9B5.6020304@article19.org> Date: Wed, 07 Oct 2015 12:53:41 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> In-Reply-To: <20151007100153.GB20416@nic.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 10:53:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks a lot for these comments Stephane. On 10/07/2015 12:01 PM, Stephane Bortzmeyer wrote: >> Please find underneath the first draft by Will on DNS, > >> The DNS system operates a centralized core of ‘Root Resolvers’ , > > Please pay attention to the terminology. There is no such thing as > a root resolver. This was probably a reference to root servers. > Also, the adjective "centralized" seems strange here. Agree. This is where we will need to get into a precise description of what centralized and distributed means. > >> servers run by a set of organizations trusted by IANA > > Precisely not (this is one of the darkest secrets of Intenet > governance). The root server operators existed long before ICANN, > the vast majority of them have zero relationshiop with ICANN and > there is no ICANN process to add or remove a root server. > This would be really interesting to dig out and describe more precisely. You got some more info, links or guidance here Stephane, or do we need to dig up 'Ruling the Root' by Milton Mueller? >> Top Level domains are maintained and determined by IANA, > > Add "acting as a delegate of the US governement" > "..even though there is currently a process ongoing to transfer this authority to the global Internet community." >> nor does it offer authentication, allowing the client to know >> that they have received a correct, “authoritative”, answer to a >> query. > > This is untrue, because of DNSSEC (which is mentioned later but > ignored in this sentence). > >> the US-based registrar in charge of the .com TLD > > Registry not registrar. > >> At a protocol level, the ability to seize domain names is enabled >> by the lack of transparency into DNS transfers, > > I do not see what is the "lack of transparency into DNS > transfers". > >> or any technical encoding of name ownership. > > Is it a reference to alternative techniques like proving name > ownership through cryptographic signatures plus a public record, > such as Namecoin? If so, it could be explained more clearly. > >> At a protocol level, the effectiveness of these attacks is made >> possible by a lack of authentication in the DNS protocol. The >> DNSSEC protocol is not widely in use, but provides an extension >> allowing the client to know that a response is ‘Authoritative’ - >> that it has been generated by the server which has technical >> ownership of the name requested. > > Self contradictory sentence: either DNSSEC exists or it doesn't. If > it exists (which is the case), there *is* "authentication in the > DNS protocol". > +1. Let's make a real clear differentiation here between what is often implemented and what is in the protocol. I think here were should solely focus on the protocol. >> Even still, there are a range of downgrade attacks, where a >> client may continue to follow the resolution of an injected >> message without such a signature, since it may not know that it >> should expect the response to be signed. > > Either there is a technical weakness in DNSSEC, allowing this > attack, and it must be published, to allow IETF to patch the DNSSEC > protocol (or to drop it), or this is pure FUD (I have no idea of > where does this sentence come from). > > Technical note: the DNS client knows that "it should expect the > response to be signed" through the DS (Delegation Signed) records. > When there is really no DS, the client knows it through "secure > denial of existence", thanks to NSEC and NSEC records. > Thanks again Stephane, really useful. Are there any other vulnerabilities you think that should be mentioned? Best, Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFPm0AAoJEAi1oPJjbWjplR8H/RFPOPxgV85eDwTkmlWEtqyi mq0TeaL2JHWVhq8ve6TkXcSEMwFaNHkoouCgMo3GTxsJzjNhgvcDGfmQnB1SECqg Qh0db33pzJlECXa7IBYp2MLP1myV/Ru7nX58CY/lAPJMuwHdKLCjiTtFC9nUHDI7 Gr16HF4/B1CAN1oGh2ozqhlTUkmsVxAC8zshXHo+zmSHlgCFxNqwVIcl7ZNwGHuL kCIWM6Ap2aT1+VIcqH1g8FJKtyXVdJczoMpd6QNEaSKjjJ2XP4C22pMa5cyFPMnP 9F6HkkoXpCWSadPxBn+8+rvWLuy6IP7s0rFAVXw7oFNrXp0k5CxP/1s4EwOAO9s= =Jf05 -----END PGP SIGNATURE----- From nobody Wed Oct 7 04:13:20 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36F1B2DEE for ; Wed, 7 Oct 2015 04:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka0ehaa0DL5A for ; Wed, 7 Oct 2015 04:13:17 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262EC1B2DCA for ; Wed, 7 Oct 2015 04:13:17 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D02BB2800F2; Wed, 7 Oct 2015 13:13:14 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id C1A1628002B; Wed, 7 Oct 2015 13:13:14 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id BD59E4C004D; Wed, 7 Oct 2015 13:12:44 +0200 (CEST) Date: Wed, 7 Oct 2015 13:12:44 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151007111244.GA29746@nic.fr> References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5614F9B5.6020304@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Stephane Bortzmeyer , "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:13:18 -0000 On Wed, Oct 07, 2015 at 12:53:41PM +0200, Niels ten Oever wrote a message of 113 lines which said: > > Precisely not (this is one of the darkest secrets of Intenet > > governance). The root server operators existed long before ICANN, > > the vast majority of them have zero relationshiop with ICANN and > > there is no ICANN process to add or remove a root server. > > This would be really interesting to dig out and describe more > precisely. You got some more info, links or guidance here Stephane, > or do we need to dig up 'Ruling the Root' by Milton Mueller? I'm afraid (from my memory) that Mueller's book does not mention the management of the root name servers. As I said, it is one of the best kept secrets of Internet governance. The professionals of the governance circus typically ignore this issue (too practical? too difficult?). > > Add "acting as a delegate of the US governement" > > "..even though there is currently a process ongoing to transfer this > authority to the global Internet community." And "Santa will give presents to nice kids at Christmas", yes. From nobody Wed Oct 7 04:46:48 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826751B2E5B for ; Wed, 7 Oct 2015 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.124 X-Spam-Level: *** X-Spam-Status: No, score=3.124 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZakgpGgfiS4d for ; Wed, 7 Oct 2015 04:46:45 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166711B2E58 for ; Wed, 7 Oct 2015 04:46:45 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id E7D3518001C; Wed, 7 Oct 2015 11:46:43 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id D238B180038; Wed, 7 Oct 2015 11:46:43 +0000 (UTC) Received: from [192.168.1.65] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id B6B6418001C; Wed, 7 Oct 2015 11:46:43 +0000 (UTC) Message-ID: <56150622.9000101@article19.org> Date: Wed, 07 Oct 2015 13:46:42 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> In-Reply-To: <20151007111244.GA29746@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?windows-1252?Q?Patrik_F=E4ltstr=F6?= =?windows-1252?Q?m?= , "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 11:46:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/07/2015 01:12 PM, Stephane Bortzmeyer wrote: > On Wed, Oct 07, 2015 at 12:53:41PM +0200, Niels ten Oever > wrote a message of 113 lines which said: > >>> Precisely not (this is one of the darkest secrets of Intenet >>> governance). The root server operators existed long before >>> ICANN, the vast majority of them have zero relationshiop with >>> ICANN and there is no ICANN process to add or remove a root >>> server. >> >> This would be really interesting to dig out and describe more >> precisely. You got some more info, links or guidance here >> Stephane, or do we need to dig up 'Ruling the Root' by Milton >> Mueller? > > I'm afraid (from my memory) that Mueller's book does not mention > the management of the root name servers. As I said, it is one of > the best kept secrets of Internet governance. The professionals of > the governance circus typically ignore this issue (too practical? > too difficult?). > This is how I understand it, but please correct me if I'm wrong (also looping in Patrik here): ICANN, under the IANA function, manages the IANA database. If changes are made, changes are subsequently checked by the NTIA. The actual changes are then made by Verisign (who have a direct contract with NTIA [0]) in the a-root. And the other 12 roots then federate from the a-root. I think this is regularly described as a hierarchical distributed system. (This definition could help us stay away from the discussion whether this is centralized or not). Question from my side: were there ever any discrepancies between the root servers, other than those caused by a time lag? >>> Add "acting as a delegate of the US governement" >> >> "..even though there is currently a process ongoing to transfer >> this authority to the global Internet community." > > And "Santa will give presents to nice kids at Christmas", yes. > Stop destroying dreams, Stephane. Hope dies last ;) But since the process is ongoing, it would be good to mention. Let's stick to the facts, no? Best, Niels [0] http://www.ntia.doc.gov/page/verisign-cooperative-agreement -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFQYiAAoJEAi1oPJjbWjpe9AH/1XUsyFqc2n9ufWIv20I4pMC JhKtxYPYe0DSn8By1qDh1b7q60b7DnpANvyDYucVgXMJ6fD6D/YE1+0GxyYVcZ1v hpeHOS2h6fuuE8RqFbp6iw3/oTcpiI8c9drmdVtGC2fKotTjKT+6//9C38Cb776B L6oMc6kycHfIsFzppwovyqiibVlMx3c0WYCi6MqU0jb3tjTtfdU0mog+tFOn/tU6 FCjzFyoTuVTAWUNmeXH6i5iM19l8AwMHtdT5UeBJSj6dq2e86aFjsZkBmmP65gZV kNOwSuD4cjTuwQ9xfcO6UfpB+25E5nt5CxAufe9kiaMptX64qE6TDJ5giCjdFs8= =+F1p -----END PGP SIGNATURE----- From nobody Wed Oct 7 07:04:11 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08F71A9128 for ; Wed, 7 Oct 2015 07:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGYUdBjSf003 for ; Wed, 7 Oct 2015 07:03:50 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 380981A9114 for ; Wed, 7 Oct 2015 07:03:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id AB2141072E for ; Wed, 7 Oct 2015 14:03:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L2C2kotxi_z for ; Wed, 7 Oct 2015 14:03:25 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:1da9:c0c9:7f08:5577:c181]) by mx2.yitter.info (Postfix) with ESMTPSA id C846510739 for ; Wed, 7 Oct 2015 14:03:25 +0000 (UTC) Date: Wed, 7 Oct 2015 10:03:24 -0400 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20151007140323.GH1389@mx2.yitter.info> References: <5614667C.5090508@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5614667C.5090508@article19.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:03:54 -0000 Hi, On Wed, Oct 07, 2015 at 02:25:32AM +0200, Niels ten Oever wrote: > The Domain Name System (DNS), as specified in RFC 1035, acts as a core > switchboard for the internet - associating human readable names with > services. This is part of what the DNS does, it's true. But the more accurate depiction is that this is an important but not only job of the DNS. The DNS is also used, for instance, in various service discovery systems. It can also be used as a rather nice way to improve user security by allowing use of strong cryptography without dependence on Certificate Authorities. > The DNS system operates a centralized core of ‘Root > Resolvers’ , servers run by a set of organizations trusted by IANA to > enact the organization’s decisions by accurately communicating which > organizations have been delegated to manage registration under each > Top Level Domain (TLD). Apart from the corrections Stephane sent, I think it's important to recognise that the DNS is not at all centralized. The DNS is arguably the most successful distributed database system ever built or operated. It is decentralized in two ways. First, the authority in the system is decentralized. When you get a domain name delegated to you, nothing about your operation of that is thereafter controlled (in a technical sense) _except_ the delegation. It's true your parent can remove the delegation, but that's all they can do. Second, it's also decentralized in operation, by virtue of caches theoretically governed by the Time To Live setting established by the zone operator. It's really radically decentralized. It's also worth noting tht the root servers are the root servers because they're the ones everyone uses. You can change this on your own resolver, if you want, by changing the root.hints file you use. Of course, if people start using various different roots, and they're not operating a single namespace, then we no longer have one Internet, but multiple. That's a risk of "multiple roots". > Top Level domains are maintained and > determined by IANA, It would be nice to draw a distinction here, because this point has caused a lot of trouble in the IANA transition this year. ICANN has two roles. IANA today (historically less so) is mostly a clerical job. So it's strictly true that IANA places the TLDs in the root zone, but it does so according to policy decisions made by ICANN in its policy-making function, and not in its IANA function. > and have evolved to encompass several classes of > services. Some, like ‘.Com’ and ‘.Net’, provide a common space for > expression of ideas, though their policies are enacted through US > based countries. The basic idea that gTLDs have any particular function is fetching but no longer really true. I don't know what a "US-based country" is, but maybe that means "company". It's true that many of the organizations operating gTLDs are US-based, but not all. For instance, Afilias operates info and is incorporated in Ireland. > has been recently expanded with the addition of “generic TLDs”, name The addition of gTLDs is not a recent expansion: that's what com and net are too. Perhaps "recently expanded with additional generic TLDs". > spaces with accompanying regulations aimed to promote expression > around specific topics, for instance ‘.travel’ and ‘.ninja’. No, the ones that have specific topics are sometimes called "sponsored TLDs", but the ICANN-level policy difference is at best minimal. The operator of any domain can make policies about what may be registered in it, and that's how the new scope-limited gTLDs are working: they adopt rules about who may register or what those registrations may be used for. Many of the new gTLDs have no different policies than com or net or org. > intermediary parties, nor does it offer authentication, allowing the > client to know that they have received a correct, “authoritative”, > answer to a query. Authentication is offered by DNSSEC, which is now enjoying some modest deployment success, so that seems not too relevant. > harm to freedom of expression as the DNS protocol has become one of > the central mechanisms used to block access to websites - limiting I think I'd say, "interference with the operation of the DNS has become one of the …". > Removal of records > - ----- > There have been a number of cases where the records for a domain are > removed from the name system due to real-world events. Examples of > this removal include ‘seizure’ of names of illegally operating > gambling operations by the United States ICE unit by compelling the > US-based registrar in charge of the .com TLD to hand ownership of > those domains over to the government. The same technique has been > notably used by Libya to remove sites in violation of “our Country’s > Law and Morality [which] do not allow any kind of pornography or its > promotion.” The DNS mechanism here is simply the ability to remove a delegation. That is the sole technical function that is invoked, and it's an administrative decision (i.e. actually a policy decision) imposed by the technical means of removal of the delegation. In the presence of DNSSEC, the delegation cannot be undetectably blocked by a third party. While it is true that detectably blocking something can suppress speech, it does so in the same way that redaction via black lines over text does: the reader can tell. > At a protocol level, the ability to seize domain names is enabled by > the lack of transparency into DNS transfers, or any technical encoding > of name ownership. This is external to the DNS, but it's not the case that there is no such transparency. That's what whois gets you. The whois (and we hope its replacement by RDAP) provides the view you're looking for. > Name ownership is purely a policy decision of > registrars. Yes. > At the national level, there are additional considerations. The most > notable is the interactions between DNS distortion and internet > routing. A study on collateral damage showed that the restrictions > imposed by China on DNS responses in its network also affected the > availability of sites to users in Germany, since some fraction of > requests would transit through the Chinese network, even though none > of the participants were located there. I think this part is conflating issues and doesn't belong here. > At a protocol level, the effectiveness of these attacks is made > possible by a lack of authentication in the DNS protocol. The DNSSEC > protocol is not widely in use, but provides an extension allowing the > client to know that a response is ‘Authoritative’ - that it has been > generated by the server which has technical ownership of the name > requested. As I note above, DNSSEC should be reflected earlier. Moreover, one can hardly claim a weakness on the grounds that people aren't using the technology available. > Even still, there are a range of downgrade attacks, where a > client may continue to follow the resolution of an injected message > without such a signature, since it may not know that it should expect > the response to be signed. If it does not know that, it hasn't performed validation. It is never possible under DNSSEC not to know that the response should be signed unless one is not validating or the name is not properly signed. > This is effective because of the DNS protocol’s decision to provide > whatever answer it receives first, and stop listening for subsequent > answers, and enabled by the lack of authentication or encryption in > the protocol. No, injection also won't work in the face of DNSSEC, either. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Oct 7 08:43:06 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE11AC42F for ; Wed, 7 Oct 2015 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Ppft7bMEmK for ; Wed, 7 Oct 2015 08:42:50 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57E81AC427 for ; Wed, 7 Oct 2015 08:42:49 -0700 (PDT) Received: by igcpe7 with SMTP id pe7so17555107igc.0 for ; Wed, 07 Oct 2015 08:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:date:message-id:subject:from:to:content-type; bh=PnwK6b+xJiOYJBUv/F5pFMg3LRo5a6IDxG1SxSVOB80=; b=R7KfRRAxmNbd7vc+OTUNzZJbVqx4EEuj9bac482BM920cmK+ulJCaFODVyi699ZJ4T 58198GprTE0kmdChedsqIHtI0gMyIIbIBd8F1m3SNI3pvANIND/URxQ5PC1CZ7k8W0jS PuThTU2lTWTIa93zmgCmrSuDry29y9tPi3yBY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PnwK6b+xJiOYJBUv/F5pFMg3LRo5a6IDxG1SxSVOB80=; b=AkszRnP+qjm3TzJVqs4l01oV96PH/hmrvtlksjCEkXrjvhNvSCO8DsN6JR7gpb2Qhu /KVLTsSlSjmu7L53/29eSmc8gqKyHhbHt3fyRQtCFzFU5XflZCXXtquShJKlFE+1ypcy H/ZhWrOmXrQHvjcYVX2Mv1pD1FBUl+OFylB56Zb30A7/OS7ci7sYz9l9NY2Rv1goW6vL 8KOTaTdPAq48nULIc1RVPSPJi9Sbofg2o1BtqKc5HgZpfxWu6/hGZHfdSvANybEQPpA2 JuYnQA2IQjyf/AZmsCcNRiucXZdpr8YSrpbYz1qlGrX7YqJxBR9O6JO+GEDDhN/gf5Rq TPmQ== X-Gm-Message-State: ALoCoQnIqLTWuj6vOvW4wc/vhANgGBztdbc6XFojiCI1XgaHntGzZPFmPObFIniAKwortDFULn5s MIME-Version: 1.0 X-Received: by 10.50.143.4 with SMTP id sa4mr2639251igb.52.1444232568916; Wed, 07 Oct 2015 08:42:48 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Wed, 7 Oct 2015 08:42:48 -0700 (PDT) Date: Wed, 7 Oct 2015 08:42:48 -0700 Message-ID: From: Will Scott To: hrpc@irtf.org Content-Type: multipart/alternative; boundary=001a1134bce23e6c8f0521859944 Archived-At: Subject: [hrpc] cases - XMPP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 15:42:52 -0000 --001a1134bce23e6c8f0521859944 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Here are initial thoughts on analysis of XMPP. If there are additional aspects you want to flag as potentials for harm, specific citations you'd like to see, or items here you'd take issue with, I'd appreciate the feedback. --Will XMPP =3D=3D=3D=3D=3D The Extensible Messaging and Presence Protocol (XMPP), specified in RFC 3920, provides a standard for interactive chat messaging, and has evolved to encompass interoperable text, voice, and video chat. The protocol is structured as a federated network of servers, similar to email, where users register with a local server which acts one their behalf to cache and relay messages. This protocol design has many advantages, allowing servers to shield clients from denial of service and other forms of retribution for their expression, and designed to avoid central entities which could control the ability to communicate or assemble using the protocol. None-the-less, there are plenty of aspects of the protocol design of XMPP which shape the ability for users to communicate freely, and to assembly through the protocol. In addition to issues of user registration and a lack of protocol specification of the registration policy, the protocol also has facets that may stifle speech as users self-censor for fear of surveillance, or find themselves unable to express themselves naturally. User Identification ------ The XMPP specification specifies that clients are identified with a resource ( / ) to distinguish the conversations to specific devices. This has the side effect of enabling tracking of user behavior by a remote friend or server, who are able to track presence not only of the user, but of each individual device. This has proven to be misleading to many users, since many clients only expose user level rather than device level presence. Likewise, user invisibility so that communication can occur while users don=E2=80=99t notify all buddie= s and other servers of their availability is not part of the formal protocol, and has only been added as an extension within the XML stream rather than enforced by the protocol. Documentation of this form of harm: [1] https://developer.pidgin.im/ticket/4322 Character Encoding ----- Localization is a source of frustration in many protocols, and appears in some forms of XMPP. The XMPP protocol specifies a requirement for UTF-8 and UTF-16 support [1], though documentation admits that many implementations may not support UTF-16 [2]. In practice, this leads to cases where text encoded outside of a standard english language ascii encoding will fail to render on all clients, limiting the ability of users to communicate in their native languages. Some examples are failure of XMPP servers to handle non-ascii passwords [3], and gateways which simply strip all non-ascii from the conversation stream. At the protocol level, XMPP only defines the conversation as an XML block, and leaves the implementation of character sets to the XMPP parsers of each individual client and server. While there have been attempts to define UTF-16 support as part of the protocol specification, the lack of actual implementation of the more extensible character set by all clients has shaped the protocol to harm the full range of expression users may desire. Documentation of this form of harm: [1] http://mail.jabber.org/pipermail/xmppwg/2003-August/001460.html [2] http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-unsupported-enco= ding [3] https://support.process-one.net/browse/EJAB-476 [4] https://wiki.bitlbee.org/HowtoFacebookXMPP Surveillance of Communication ----- The XMPP protocol specifies the standard by which communication of channels may be encrypted, but it does not provide visibility to clients of whether their communications are encrypted on each link. In particular, even when both clients ensure that they have an encrypted connection to their XMPP server to ensure that their local network is unable to read or disrupt the messages they send, the protocol does not provide visibility into the encryption status between the two servers. As such, clients may be subject to selective disruption of communications by an intermediate network which disrupts communications based on keywords found through Deep Packet Inspection. In particular, section 13.14 of the protocol specification [2] explicitly acknowledges the existence of a downgrade attack where an adversary controlling an intermediate network can force the inter domain federation between servers to revert to a non-encrypted protocol were selective messages can then be disrupted. Documentation of this form of harm: [1] https://raw.githubusercontent.com/stpeter/manifesto/master/manifesto.tx= t [2] https://www.ietf.org/rfc/rfc6120.txt Group Chat Limitations ----- Group chat in the XMPP protocol is defined as an extension within the XML specification of the XMPP protocol [1]. However, it is not encoded or required at a protocol level, and not uniformly implemented by clients. The design of multi-user chat in the XMPP protocol suffers from extending a protocol that was not designed with assembly of many users in mind. In particular, in the federated protocol provided by XMPP, multi-user communities are implemented with a distinguished =E2=80=98owner=E2=80=99, w= ho is granted control over the participants and structure of the conversation. Multi-user chat rooms are identified by a name specified on a specific server, so that while the overall protocol may be federated, the ability for users to assemble in a given community is moderated by a single server. That server may block the room and prevent assembly unilaterally, even between two users neither of whom trust or use that server directly. [1] http://xmpp.org/extensions/xep-0045.html --001a1134bce23e6c8f0521859944 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Here are initial thoughts on an= alysis of XMPP.
If there are additional aspects you want to flag = as potentials for harm, specific citations you'd like to see, or items = here you'd take issue with, I'd appreciate the feedback.
=
--Will

XMPP
=3D=3D=3D=3D= =3D
The Extensible Messaging and Presence Protocol (XMPP), specif= ied in RFC 3920, provides a standard for interactive chat messaging, and ha= s evolved to encompass interoperable text, voice, and video chat. The proto= col is structured as a federated network of servers, similar to email, wher= e users register with a local server which acts one their behalf to cache a= nd relay messages. This protocol design has many advantages, allowing serve= rs to shield clients from denial of service and other forms of retribution = for their expression, and designed to avoid central entities which could co= ntrol the ability to communicate or assemble using the protocol.
=
None-the-less, there are plenty of aspects of the protocol d= esign of XMPP which shape the ability for users to communicate freely, and = to assembly through the protocol. In addition to issues of user registratio= n and a lack of protocol specification of the registration policy, the prot= ocol also has facets that may stifle speech as users self-censor for fear o= f surveillance, or find themselves unable to express themselves naturally.<= /div>

User Identification
------
The= XMPP specification specifies that clients are identified with a resource (= <node@domain/home> / <node@domain/work>) to distinguish the con= versations to specific devices. This has the side effect of enabling tracki= ng of user behavior by a remote friend or server, who are able to track pre= sence not only of the user, but of each individual device. This has proven = to be misleading to many users, since many clients only expose user level r= ather than device level presence. Likewise, user invisibility so that commu= nication can occur while users don=E2=80=99t notify all buddies and other s= ervers of their availability is not part of the formal protocol, and has on= ly been added as an extension within the XML stream rather than enforced by= the protocol.

Documentation of this form of harm:=

Character Enco= ding
-----
Localization is a source of frustration in m= any protocols, and appears in some forms of XMPP. The XMPP protocol specifi= es a requirement for UTF-8 and UTF-16 support [1], though documentation adm= its that many implementations may not support UTF-16 [2]. In practice, this= leads to cases where text encoded outside of a standard english language a= scii encoding will fail to render on all clients, limiting the ability of u= sers to communicate in their native languages. Some examples are failure of= XMPP servers to handle non-ascii passwords [3], and gateways which simply = strip all non-ascii from the conversation stream.

= At the protocol level, XMPP only defines the conversation as an XML block, = and leaves the implementation of character sets to the XMPP parsers of each= individual client and server. While there have been attempts to define UTF= -16 support as part of the protocol specification, the lack of actual imple= mentation of the more extensible character set by all clients has shaped th= e protocol to harm the full range of expression users may desire.

Documentation of this form of harm:

Survei= llance of Communication
-----
The XMPP protocol specifi= es the standard by which communication of channels may be encrypted, but it= does not provide visibility to clients of whether their communications are= encrypted on each link. In particular, even when both clients ensure that = they have an encrypted connection to their XMPP server to ensure that their= local network is unable to read or disrupt the messages they send, the pro= tocol does not provide visibility into the encryption status between the tw= o servers. As such, clients may be subject to selective disruption of commu= nications by an intermediate network which disrupts communications based on= keywords found through Deep Packet Inspection.

In= particular, section 13.14 of the protocol specification [2] explicitly ack= nowledges the existence of a downgrade attack where an adversary controllin= g an intermediate network can force the inter domain federation between ser= vers to revert to a non-encrypted protocol were selective messages can then= be disrupted.

Documentation of this form of harm:=



Group Chat Limitations
-----<= /div>
Group chat in the XMPP protocol is defined as an extension within= the XML specification of the XMPP protocol [1]. However, it is not encoded= or required at a protocol level, and not uniformly implemented by clients.=

The design of multi-user chat in the XMPP protoco= l suffers from extending a protocol that was not designed with assembly of = many users in mind. In particular, in the federated protocol provided by XM= PP, multi-user communities are implemented with a distinguished =E2=80=98ow= ner=E2=80=99, who is granted control over the participants and structure of= the conversation.

Multi-user chat rooms are ident= ified by a name specified on a specific server, so that while the overall p= rotocol may be federated, the ability for users to assemble in a given comm= unity is moderated by a single server. That server may block the room and p= revent assembly unilaterally, even between two users neither of whom trust = or use that server directly.


--001a1134bce23e6c8f0521859944-- From nobody Wed Oct 7 10:55:58 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2873F1ACD62 for ; Wed, 7 Oct 2015 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZn2TRU3O8xc for ; Wed, 7 Oct 2015 10:55:54 -0700 (PDT) Received: from EXC-MBX2.INTERNEWS.LOCAL (mxout.internews.org [70.33.180.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46921ACD65 for ; Wed, 7 Oct 2015 10:55:53 -0700 (PDT) Received: from flower.device (38.88.234.58) by EXC-MBX2.INTERNEWS.LOCAL (10.10.40.50) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 7 Oct 2015 10:57:23 -0700 From: seamus tuohy To: Niels ten Oever , Stephane Bortzmeyer In-Reply-To: <5614F9B5.6020304@article19.org> References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> User-Agent: Notmuch/0.20.2+73~gd432116 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 7 Oct 2015 13:55:50 -0400 Message-ID: <87twq24l7d.fsf@flower.device> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [38.88.234.58] X-ClientProxiedBy: EXC-CAS2.INTERNEWS.LOCAL (10.10.40.30) To EXC-MBX2.INTERNEWS.LOCAL (10.10.40.50) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 17:55:57 -0000 Niels ten Oever writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Thanks a lot for these comments Stephane. > > On 10/07/2015 12:01 PM, Stephane Bortzmeyer wrote: >>> Please find underneath the first draft by Will on DNS, >> >>> The DNS system operates a centralized core of =E2=80=98Root Resolvers= =E2=80=99 , >> >> Please pay attention to the terminology. There is no such thing as >> a root resolver. This was probably a reference to root servers. >> Also, the adjective "centralized" seems strange here. > > Agree. This is where we will need to get into a precise description of > what centralized and distributed means. > >> >>> servers run by a set of organizations trusted by IANA >> >> Precisely not (this is one of the darkest secrets of Intenet >> governance). The root server operators existed long before ICANN, >> the vast majority of them have zero relationshiop with ICANN and >> there is no ICANN process to add or remove a root server. >> > > This would be really interesting to dig out and describe more > precisely. You got some more info, links or guidance here Stephane, or > do we need to dig up 'Ruling the Root' by Milton Mueller? > >>> Top Level domains are maintained and determined by IANA, >> >> Add "acting as a delegate of the US governement" >> > > "..even though there is currently a process ongoing to transfer this > authority to the global Internet community." > >>> nor does it offer authentication, allowing the client to know >>> that they have received a correct, =E2=80=9Cauthoritative=E2=80=9D, ans= wer to a >>> query. >> >> This is untrue, because of DNSSEC (which is mentioned later but >> ignored in this sentence). >> >>> the US-based registrar in charge of the .com TLD >> >> Registry not registrar. >> >>> At a protocol level, the ability to seize domain names is enabled >>> by the lack of transparency into DNS transfers, >> >> I do not see what is the "lack of transparency into DNS >> transfers". >> >>> or any technical encoding of name ownership. >> >> Is it a reference to alternative techniques like proving name >> ownership through cryptographic signatures plus a public record, >> such as Namecoin? If so, it could be explained more clearly. >> >>> At a protocol level, the effectiveness of these attacks is made >>> possible by a lack of authentication in the DNS protocol. The >>> DNSSEC protocol is not widely in use, but provides an extension >>> allowing the client to know that a response is =E2=80=98Authoritative= =E2=80=99 - >>> that it has been generated by the server which has technical >>> ownership of the name requested. >> >> Self contradictory sentence: either DNSSEC exists or it doesn't. If >> it exists (which is the case), there *is* "authentication in the >> DNS protocol". >> > > +1. Let's make a real clear differentiation here between what is often > implemented and what is in the protocol. I think here were should > solely focus on the protocol. > If the focus is solely on the current protocol then it would seem there is no use to go into any of the social or political flaws in the current root server or name server structure and organization. I would posit that the motivations behind the creation of RFC 4033 are very relevant to this discussion. A simple enumeration of the current flaws or benefits within these documents would ignore the rich history of the IETF responding to perceived flaws that have, or will lead to human rights violations. I am sure there is far more context to be found in the archive of the 4033 email list that may directly talk to the incidents that inspired its creation, but the first draft included a threat model section that exposes some of context. "Threat Model The Domain Name System (DNS) protocol has been the target of several well-publicized attacks since it's creation. These attacks are centered on altering DNS traffic in transit, or sending erroneous referral messages to caching servers (i.e. "cache poisoning"). The result of these attacks are traffic redirection or complete "zone hijacking" if the malicious referral code is allowed to propagate." The "well-publicized attacks" that spawned the creation of DNSSEC hint at how wide scale human-rights abuses have, and should, be taken into consideration in the creation and revision of Internet protocols. I think the history of protocols that have changed, possibly because of human rights concerns, are as important as their current possible ability to harm/strengthen human rights because it provides us concrete protocol issues that have been addressed in the past, and a glimpse at how protocol level changes can be made to directly respond to flawed social or political structures and abuses. >>> Even still, there are a range of downgrade attacks, where a >>> client may continue to follow the resolution of an injected >>> message without such a signature, since it may not know that it >>> should expect the response to be signed. >> >> Either there is a technical weakness in DNSSEC, allowing this >> attack, and it must be published, to allow IETF to patch the DNSSEC >> protocol (or to drop it), or this is pure FUD (I have no idea of >> where does this sentence come from). >> >> Technical note: the DNS client knows that "it should expect the >> response to be signed" through the DS (Delegation Signed) records. >> When there is really no DS, the client knows it through "secure >> denial of existence", thanks to NSEC and NSEC records. >> > > Thanks again Stephane, really useful. Are there any other > vulnerabilities you think that should be mentioned? > > Best, > > Niels > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWFPm0AAoJEAi1oPJjbWjplR8H/RFPOPxgV85eDwTkmlWEtqyi > mq0TeaL2JHWVhq8ve6TkXcSEMwFaNHkoouCgMo3GTxsJzjNhgvcDGfmQnB1SECqg > Qh0db33pzJlECXa7IBYp2MLP1myV/Ru7nX58CY/lAPJMuwHdKLCjiTtFC9nUHDI7 > Gr16HF4/B1CAN1oGh2ozqhlTUkmsVxAC8zshXHo+zmSHlgCFxNqwVIcl7ZNwGHuL > kCIWM6Ap2aT1+VIcqH1g8FJKtyXVdJczoMpd6QNEaSKjjJ2XP4C22pMa5cyFPMnP > 9F6HkkoXpCWSadPxBn+8+rvWLuy6IP7s0rFAVXw7oFNrXp0k5CxP/1s4EwOAO9s=3D > =3DJf05 > -----END PGP SIGNATURE----- > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc -- seamus tuohy | Sr. Technologist - Internet Initiatives stuohy@internews.org Skype/XMPP on request PGP: D9F9 B306 4FDF 373D 1025 4313 2CF2 3545 F2D7 DAC4 MiniLock: 2G3JmRWRYB3B7rthZqkzomcRe8GwJvPtSooA748XMsTBdf INTERNEWS | Local Voices. Global Change. www.internews.org | @internews From nobody Wed Oct 7 17:28:13 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D201B2DDF for ; Wed, 7 Oct 2015 17:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFT68E4ckEpB for ; Wed, 7 Oct 2015 17:28:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295CD1B2D5E for ; Wed, 7 Oct 2015 17:28:09 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DFC7C22E25F for ; Wed, 7 Oct 2015 20:28:01 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2015 11:27:58 +1100 References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> To: hrpc@irtf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 00:28:11 -0000 FYI, I've been working on this for a little while.=20 I'm not sure HPRC is the right place for this to end up; talking to some = people "in the know", it seems like this might need to go through the = GEN area if we want it to stick. However, I'd love to hear feedback from = HPRC folks. Also, a possibly more friendly HTML version is at: http://mnot.github.io/I-D/for-the-users/ Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-for-the-users-01.txt > Date: 8 October 2015 11:24:12 am AEDT > To: "Mark Nottingham" , "Mark Nottingham" = >=20 >=20 > A new version of I-D, draft-nottingham-for-the-users-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-for-the-users > Revision: 01 > Title: The Internet is for End Users > Document date: 2015-10-08 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-01.txt= > Status: = https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-for-the-users-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-for-the-users-01 >=20 > Abstract: > Internet standards serve and are used by a variety of communities. > This document contains guidelines for explicitly identifying them, > serving them, and determining how to resolve conflicts between their > interests, when necessary. >=20 > It also mandates end users as the highest priority concern for > Internet standards. >=20 > Note to Readers >=20 > The issues list for this draft can be found at > https://github.com/mnot/I-D/labels/for-the-users . >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 7 17:30:35 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42A41B30EA for ; Wed, 7 Oct 2015 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2vyZ4sJCK2M for ; Wed, 7 Oct 2015 17:30:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8F91B2E33 for ; Wed, 7 Oct 2015 17:30:32 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B44AC22E260 for ; Wed, 7 Oct 2015 20:30:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Thu, 8 Oct 2015 11:30:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <94576EA2-31BF-4185-A860-29FBC879C331@mnot.net> References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> To: hrpc@irtf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 00:30:33 -0000 Sorry, HRPC :) > On 8 Oct 2015, at 11:27 am, Mark Nottingham wrote: >=20 > FYI, I've been working on this for a little while.=20 >=20 > I'm not sure HPRC is the right place for this to end up; talking to = some people "in the know", it seems like this might need to go through = the GEN area if we want it to stick. However, I'd love to hear feedback = from HPRC folks. >=20 > Also, a possibly more friendly HTML version is at: > http://mnot.github.io/I-D/for-the-users/ >=20 > Cheers, >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-nottingham-for-the-users-01.txt >> Date: 8 October 2015 11:24:12 am AEDT >> To: "Mark Nottingham" , "Mark Nottingham" = >>=20 >>=20 >> A new version of I-D, draft-nottingham-for-the-users-01.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >>=20 >> Name: draft-nottingham-for-the-users >> Revision: 01 >> Title: The Internet is for End Users >> Document date: 2015-10-08 >> Group: Individual Submission >> Pages: 8 >> URL: = https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-01.txt= >> Status: = https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >> Htmlized: = https://tools.ietf.org/html/draft-nottingham-for-the-users-01 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-for-the-users-01 >>=20 >> Abstract: >> Internet standards serve and are used by a variety of communities. >> This document contains guidelines for explicitly identifying them, >> serving them, and determining how to resolve conflicts between their >> interests, when necessary. >>=20 >> It also mandates end users as the highest priority concern for >> Internet standards. >>=20 >> Note to Readers >>=20 >> The issues list for this draft can be found at >> https://github.com/mnot/I-D/labels/for-the-users . >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 7 18:00:33 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9BE1B2C3F for ; Wed, 7 Oct 2015 18:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqEqevRfWZFo for ; Wed, 7 Oct 2015 18:00:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D107B1B2C6E for ; Wed, 7 Oct 2015 18:00:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6955BE59; Thu, 8 Oct 2015 02:00:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysxR6ejjHsI1; Thu, 8 Oct 2015 02:00:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7391BE58; Thu, 8 Oct 2015 02:00:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444266025; bh=ZFBMYxYQylbLZaqKtxXfHHmBqfetxlFl6Bf3vOi2kB0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=j8wHRPNULzCGX/O/Jvp6TOhWgrhIefj0GhFA6aihPKNR61+NMtNwC/3TVJO55ksgU PcjQ2Q4MNZHj2Tk0qFYO6sGCMsrMEsWmn9s7Q8lv9JnRj7uZlH1tqAQpkD5JrDlfvM u7bm9CW6UqoMZhKhHa+gQ1G+R18KwHVNJ9UblYII= To: Mark Nottingham , hrpc@irtf.org References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <5615C028.4050506@cs.tcd.ie> Date: Thu, 8 Oct 2015 02:00:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 01:00:33 -0000 Good stuff. I'm not sure end-user is the right term but I do think there's a valuable thing in your draft. I hope you persevere with it. More or less random comments, for none of which I have an answer to suggest, sorry. - I don't know how a routing person could use this as a guide for how to act - perhaps this is really an application layer concept, or maybe there's a good generalisation that could be made, I'm not sure. But considering that seems like a thing that ought be done. (You may have done it, but that's not visible in the draft.) - If end-users like something that's not really good for them (e.g. handing over all their personal information to a few mega-companies) then are we supposed to prioritise things based on how they behave or how we think they ought behave? (Or even on how we think we ought behave..) - The set of identifiable parties doesn't only include those who benefit from our standards, but also those who lose, e.g. hopefully criminals and spooks will lose, but so will some companies with some business models, and so will some sets of people. That can be important when considering trade-offs in that the delta in outcome for a losing class of persons may be a good, or a bad, thing. - If we achieve rough consensus on this text, are we then saying that this newly BCP'd principle trumps rough consensus? - "core values" - I'm not sure we have one set of those that we all agree to, and perhaps we don't need that if we have a scheme like rough consensus (see previous point) - "Extensions to existing standards MUST document..." - that's not going to happen and, I suspect, if ever reduced to concrete steps would end up as mere pointless bureaucracy, - The use of "MAY estimate" puzzles me - what does it mean? - "informed consent" - I think that's a fiction and a damaging one, being impossible and yet used to justify lots of things, at least as mostly used. - I'm not sure the HTTPS as a two party protocol is a good way to look at things. Today, a web transaction often involves a user, operating system, browser, network operator, maybe some proxies, a data centre/hosting/cloudy provider, a web server operator, and only then we get to what the user may perceive as being the 2nd party. (Which party can also be a whole menagerie of entities, an inbound proxy or load balancer, a web front-end, ...) And all of that omits the DNS entities, the spooks listening in and probably more. - I'm really unsure this is something on which we could reach rough consensus, but tha's the kind of thing I think is worth finding out. Later though. - In the meantime, I hope this is on some agenda in Yokohama and for discussion over some beers. More nitty things: - I don't think the code-regulates quote is useful, personally I find it problematic, and all you need to say is that the code that implements RFCs has obvious impact - It's somehow cute that you choose 6525 as an example of harm;-) - This really reads like something that a functioning IAB would produce, I'm not sure what conclusion to draw from the fact that this is being offered for discussion to a list that is not even a formally chartered IRTF RG. Mostly, I guess that's good. But maybe it'd be better if the IAB were emitting such drafts. (Well, so long as the content wasn't mad of course:-) Cheers, S. On 08/10/15 01:27, Mark Nottingham wrote: > FYI, I've been working on this for a little while. > > I'm not sure HPRC is the right place for this to end up; talking to some people "in the know", it seems like this might need to go through the GEN area if we want it to stick. However, I'd love to hear feedback from HPRC folks. > > Also, a possibly more friendly HTML version is at: > http://mnot.github.io/I-D/for-the-users/ > > Cheers, > > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-nottingham-for-the-users-01.txt >> Date: 8 October 2015 11:24:12 am AEDT >> To: "Mark Nottingham" , "Mark Nottingham" >> >> >> A new version of I-D, draft-nottingham-for-the-users-01.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name: draft-nottingham-for-the-users >> Revision: 01 >> Title: The Internet is for End Users >> Document date: 2015-10-08 >> Group: Individual Submission >> Pages: 8 >> URL: https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-01.txt >> Status: https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >> Htmlized: https://tools.ietf.org/html/draft-nottingham-for-the-users-01 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-01 >> >> Abstract: >> Internet standards serve and are used by a variety of communities. >> This document contains guidelines for explicitly identifying them, >> serving them, and determining how to resolve conflicts between their >> interests, when necessary. >> >> It also mandates end users as the highest priority concern for >> Internet standards. >> >> Note to Readers >> >> The issues list for this draft can be found at >> https://github.com/mnot/I-D/labels/for-the-users . >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > From nobody Thu Oct 8 07:34:46 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56CA1A1A14 for ; Thu, 8 Oct 2015 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.724 X-Spam-Level: ** X-Spam-Status: No, score=2.724 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, MANGLED_MARKET=2.3, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsgPUhSMJxlR for ; Thu, 8 Oct 2015 07:34:42 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CB11A1A13 for ; Thu, 8 Oct 2015 07:34:40 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 11F3481C9 for ; Thu, 8 Oct 2015 14:34:39 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 0125881D1 for ; Thu, 8 Oct 2015 14:34:39 +0000 (UTC) Received: from [192.168.1.65] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id E8B9F81C9 for ; Thu, 8 Oct 2015 14:34:38 +0000 (UTC) Message-ID: <56167EFE.8030406@article19.org> Date: Thu, 08 Oct 2015 16:34:38 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: hrpc@irtf.org References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> <5615C028.4050506@cs.tcd.ie> In-Reply-To: <5615C028.4050506@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 14:34:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Mark et all, Thanks for posting this here. I think this is a valuable place to discuss this draft because we're working on similar issues here, things that might eventually converge (since human rights are individual rights), but where it's home should be, I leave it to you. I would be more than happy to add a discussion of this draft (no strings attached) to the agenda of the hrpc session in Yokohama. I have some similar remarks to Stephen. There are quite some considerations in there, but not as many guidelines as one would hope. There are MUST, SHOULDs and MAYs in there, but not as many descriptions of how this should be done. Where is comes to value neutrality and objective of the IETF, you might want to refer to RFC3935 - IETFs mission statement - which reads: [QUOTE] The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. [/QUOTE] Or perhaps to RFC1958. Some responses to Stephen comments: On 10/08/2015 03:00 AM, Stephen Farrell wrote: > - If end-users like something that's not really good for them (e.g. > handing over all their personal information to a few > mega-companies) then are we supposed to prioritise things based on > how they behave or how we think they ought behave? (Or even on how > we think we ought behave..) Prioritize things on how we think the interests of the user are best protected (as described in IETF standards), which they can choose to ignore. The other way around is much harder, no? > - The set of identifiable parties doesn't only include those who > benefit from our standards, but also those who lose, e.g. hopefully > criminals and spooks will lose, but so will some companies with > some business models, and so will some sets of people. That can be > important when considering trade-offs in that the delta in outcome > for a losing class of persons may be a good, or a bad, thing. +100. If one reaches a decision, all parts of the decision making process should be made transparent. This will make future decision making much easier as well. > - If we achieve rough consensus on this text, are we then saying > that this newly BCP'd principle trumps rough consensus? Depends how these would be formulated, right? As guidelines, need for documentation, tool in the decision making process, or preconditions for new RFCs. If it would be the latter, if would be a criterium for IESG review, righ t? But I guess it's more likely to take the form of (several of) the former . > - "core values" - I'm not sure we have one set of those that we all > agree to, and perhaps we don't need that if we have a scheme like > rough consensus (see previous point) There definitely are values, also expressed in RFCs. Do you think that consensus also trumps those? That would make rough consensus 'the ultimate value / touchstone'. > - "Extensions to existing standards MUST document..." - that's not > going to happen and, I suspect, if ever reduced to concrete steps > would end up as mere pointless bureaucracy, - The use of "MAY > estimate" puzzles me - what does it mean? - "informed consent" - I > think that's a fiction and a damaging one, being impossible and yet > used to justify lots of things, at least as mostly used. +100. Informed consent is inherently broken (and "I have read and agree with the terms and conditions' is the most prevalent lie on the Internet) as shown in several articles: Prof. Daniel Solove's article on why consent is broken http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171018 Lorrie Cranor & Aleecia MacDonald article on how it would take 76 days to read privacy policies for services an average user uses (old but gold) - http://lorrie.cranor.org/pubs/readingPolicyCost-authorDraft.pdf > - I'm not sure the HTTPS as a two party protocol is a good way to > look at things. Today, a web transaction often involves a user, > operating system, browser, network operator, maybe some proxies, a > data centre/hosting/cloudy provider, a web server operator, and > only then we get to what the user may perceive as being the 2nd > party. (Which party can also be a whole menagerie of entities, an > inbound proxy or load balancer, a web front-end, ...) And all of > that omits the DNS entities, the spooks listening in and probably > more. - I'm really unsure this is something on which we could reach > rough consensus, but tha's the kind of thing I think is worth > finding out. Later though. Yes. > - In the meantime, I hope this is on some agenda in Yokohama and > for discussion over some beers. > As said, happy to put it on the agenda of the hrpc session. > More nitty things: > > - I don't think the code-regulates quote is useful, personally I > find it problematic, and all you need to say is that the code that > implements RFCs has obvious impact And you could illustrate that with the IETF statements, which probably makes it stronger in IETF fora. > - It's somehow cute that you choose 6525 as an example of harm;-) - > This really reads like something that a functioning IAB would > produce, I'm not sure what conclusion to draw from the fact that > this is being offered for discussion to a list that is not even a > formally chartered IRTF RG. Mostly, I guess that's good. But maybe > it'd be better if the IAB were emitting such drafts. (Well, so long > as the content wasn't mad of course:-) > Not sure if I understand this process suggestion since Mark is not in the IAB, right? > Cheers, S. > Cheers, ~n., > > > On 08/10/15 01:27, Mark Nottingham wrote: >> FYI, I've been working on this for a little while. >> >> I'm not sure HPRC is the right place for this to end up; talking >> to some people "in the know", it seems like this might need to go >> through the GEN area if we want it to stick. However, I'd love to >> hear feedback from HPRC folks. >> >> Also, a possibly more friendly HTML version is at: >> http://mnot.github.io/I-D/for-the-users/ >> >> Cheers, >> >> >> >>> Begin forwarded message: >>> >>> From: internet-drafts@ietf.org Subject: New Version >>> Notification for draft-nottingham-for-the-users-01.txt Date: 8 >>> October 2015 11:24:12 am AEDT To: "Mark Nottingham" >>> , "Mark Nottingham" >>> >>> >>> A new version of I-D, draft-nottingham-for-the-users-01.txt has >>> been successfully submitted by Mark Nottingham and posted to >>> the IETF repository. >>> >>> Name: draft-nottingham-for-the-users Revision: 01 Title: The >>> Internet is for End Users Document date: 2015-10-08 Group: >>> Individual Submission Pages: 8 URL: >>> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users- 01.txt >>> >>> Status: https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-nottingham-for-the-users-01 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-01 >>> >>> >>> Abstract: >>> Internet standards serve and are used by a variety of >>> communities. This document contains guidelines for explicitly >>> identifying them, serving them, and determining how to resolve >>> conflicts between their interests, when necessary. >>> >>> It also mandates end users as the highest priority concern for >>> Internet standards. >>> >>> Note to Readers >>> >>> The issues list for this draft can be found at >>> https://github.com/mnot/I-D/labels/for-the-users . >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time >>> of submission until the htmlized version and diff are available >>> at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> -- Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ hrpc mailing >> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >> > > _______________________________________________ hrpc mailing list > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFn7+AAoJEAi1oPJjbWjpU/AH/2Bdqey2KOkLAhxflsbxsJtu xoR9E6I4PnRtsAKAgYJ0KxBaJpxEiBKi2lsIURp8IDI8HmSZgRhU7X1F6+ev4xm/ IxQDLg21GISubhzvyYeTSnB78fwZV0fLwM1GvKy205dDrcEfvxGyB6zTp2uypKXr sSedw7TqCNsu9ost0LetjacjnYW828ejSl3MG1ImCYQMXgtbRsax5jYyxu9LNZP0 vdnsnfKQtWUA6fFdFC7R2ooQMmxW2vK5lQbqHZK9JyqZAcF4yIE4bppESgYForSm HnhFVgdP03MAhheaVjnqU7FcmijWasJ9x2mcgd/w6AynsYjpl33JX+9HnjOKOHc= =7bGk -----END PGP SIGNATURE----- From nobody Fri Oct 9 11:28:46 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EFE1B49AE for ; Fri, 9 Oct 2015 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5DaFn-xxXF8 for ; Fri, 9 Oct 2015 11:28:38 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FE01B49A8 for ; Fri, 9 Oct 2015 11:28:38 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so41385269igc.1 for ; Fri, 09 Oct 2015 11:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:date:message-id:subject:from:to:content-type; bh=kWJmIYEjNsHlBh4iyA0XVVPoQdevzjWFXiyrqHWJkNw=; b=Lfl1UkL4yjMLxqA+IIF9Noy5tywJFfwVpHb6XXD8ni/iDQLGrQamIaPDdaEljbgDR+ I3T7Ly2LBBRTTvn1/VfAMKeqf4CpRifnycxb6qx6973avgsesOfARbCjF7968Mt6+K2T 2nD+jdhYBCeuIjqcSSbBoYlV5RgrCo0Jj7Zig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kWJmIYEjNsHlBh4iyA0XVVPoQdevzjWFXiyrqHWJkNw=; b=KLWtaoFKzdms12yjAwYLIcYRhOXK8dw+YuSMamx0Lom0YUS9zA2FC1WUYwOPzFFTRQ hJJGEdfMjhBfR1Jx8tR3TOOXhQgSCRyM6h8ojSO57t3/twU+brGtkO3H0d8ACUqo7VtI HKZ3Qpt+lMq/k57RIoroqYqBi35Fnx/pdH/OHYEr3M2oUzYdIftfcuznm+tCReZhd9pO DVvbUjoj7ndmWFoTInfq3s9jUd6EWRxUZQlMJAHThT2wNpLUDHFHJgnewe4CDaK06rl2 9qe1j/nwVJSlObWIYFLay6orXjRIAyPr61AyCW9io20LwD0RtVgK/szwYRZByffyZKYJ lL2Q== X-Gm-Message-State: ALoCoQmZ/rKZDhZF4jAaIz8yQj+wpZBYsDP9r4G0zc//3rLTspV1idy5oRfAOZZTbJkIaIPP9fb7 MIME-Version: 1.0 X-Received: by 10.50.138.73 with SMTP id qo9mr887306igb.28.1444415317731; Fri, 09 Oct 2015 11:28:37 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Fri, 9 Oct 2015 11:28:37 -0700 (PDT) Date: Fri, 9 Oct 2015 11:28:37 -0700 Message-ID: From: Will Scott To: hrpc@irtf.org Content-Type: multipart/alternative; boundary=001a1134bae0ec06520521b0257f Archived-At: Subject: [hrpc] cases - IP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 18:28:44 -0000 --001a1134bae0ec06520521b0257f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Below is an initial discussion on tradeoffs at the IPv4 level, and specifically harms associated with RFC791. Again, if there are other protocol related harms you'd like to see flagged, feedback is welcome! --Will IP =3D=3D=3D=3D=3D The Internet Protocol version 4, known as =E2=80=98layer 3=E2=80=99 of the = internet, and specified as a common encapsulation and protocol header, is defined by RFC 791. The evolution of Internet communications have led to continued development in this area, encapsulated in the development of version 6 of the protocol in RFC 2460. In spite of this updated protocol, we find that 25 years after the specification of version 6 of the protocol, the older v4 standard continues to account for a sizable majority of internet traffic. The internet was designed as a platform for free and open communication, most notably encoded in the end-to-end principle, and that philosophy is also present in the technical implementation of the Internet Protocol. [1] While the protocol was designed to exist in an environment where intelligence is at the end hosts, it has proven to provide sufficient information that a more intelligent network core can make policy decisions and enforce policy shaping and restricting the communications of end hosts. These capabilities for network control and limitations of the freedom of expression by end hosts can be traced back to the IPv4 design, helping us understand which technical protocol decisions have led to harm of these human rights. Two major shifts have occurred to harm freedom of expression through misuse of the Internet Protocol. The first is the network=E2=80=99s exploitation o= f the public visibility of the host pairs for all communications, and the corresponding ability to discriminate and block traffic as a result of that metadata. The second is the selective development of IP options, so that protocol extensions promoting assembly and expression like Mobility and Multicasting can fail to receive support from IP compatible devices. This lack of forward compatibility where extensions can receive a baseline level of support needed to extend the design has stymied forms of expression which could have been extended to support these human rights. [1] https://www.ietf.org/rfc/rfc3724.txt Network visibility of Source and Destination ----- The IPv4 protocol header contains fixed location fields for both the source and destination IP addresses [1]. These addresses identify both the host sending and receiving each message, and allow the core network to understand who is talking to whom, and to practically limit communication selectively between pairs of hosts. Blocking of communication based on the pair of source and destination is one of the most common limitations on the ability for hosts to communicate today, [2] and can be seen as a restriction of the ability for those hosts to assemble or to consensually express themselves. We have seen from other instantiations of protocols, even those comparable to IPv4, that other designs are possible. IPv4 even encodes a defined option and specification for source routing of packets, where the source can specify or suggest a routing path, and as the message passes through those paths, the part of the path it has completed are removed from the path. This design has the potential to make it much more difficult for an individual router in the network to stifle speech, since it will cannot do the same level of differentiation on the source of the messages. Unfortunately, many networks prevent the use of source routing, and the protocol is not designed such that support of that ability is required in order for the protocol to be implemented. Documentation of this form of harm: [1] https://tools.ietf.org/html/rfc791 [2] http://www.caida.org/publications/papers/2014/outages_censorship/outages_ce= nsorship.pdf [3] http://www.ipjustice.org/digital-rights/internet-infrastructure-and-ip-cens= orship-by-david-post/ Protocols ----- The other major feature of the IP protocol header is that it specifies the protocol encapsulated in each message in an easily observable form, and does not encourage a design where the encapsulated protocol is not available to a network observer. This design has resulted in a proliferation of routers which inspect the inner protocol, and has resulted in a stagnation where only the TCP and UDP protocols are widely supported across the Internet. While the IP protocol was designed as the entire set of metadata needed for routing, subsequent enhanced routers have found value on making policy decisions based on the contents of TCP and UDP headers as well, and are encoded with the assumption that only these protocols will be used for data transfer. [1] This has prevented development of more secure protocols, since there=E2=80=99s a need to provi= de sufficient metadata with each message for routers to make positive policy decisions if you hope the protocol will be available to all users. Documentation of this form of harm: [1] https://www.chromium.org/spdy/spdy-whitepaper [2] https://www.chromium.org/quic [3] https://tools.ietf.org/html/rfc4960 Address Translation and Mobility ----- A major structural shift in the Internet which has undermined the protocol design of IPv4, and has significantly reduced the freedom of end users to communicate and assemble in the introduction network address translation. [1] Network address translation is a process whereby organizations and autonomous systems to connect two networks by translating the IPv4 source and destination addresses between the two. This process puts the router performing the translation into a privileged position, where it can decide which subset of communications are worthy of translation, and whether an unknown request for communication will be correctly forwarded to a host on the other network. This process of translation has widespread adoption despite promoting a process that goes against the stated end-to-end process of the underlying protocol [2]. In contrast, the proposed mechanism to provide support for mobility and forwarding to clients which may move, encoded instead as an option in the IP protocol [3], has failed to gain traction. This situation again suggests that the compromise made in design of the protocol has resulted in a technology which failed to technical encode the freedom of expression goals it was designed to promote. Documentation of this form of harm: [1] https://tools.ietf.org/html/rfc1631 [2] http://www.icsi.berkeley.edu/pubs/networking/NATusage11.pdf [3] https://tools.ietf.org/html/rfc5944 --001a1134bae0ec06520521b0257f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Below is an initial discussion = on tradeoffs at the IPv4 level, and specifically harms associated with RFC7= 91. Again, if there are other protocol related harms you'd like to see = flagged, feedback is welcome!

--Will
IP
=3D=3D=3D=3D=3D
The Internet Protocol ve= rsion 4, known as =E2=80=98layer 3=E2=80=99 of the internet, and specified = as a common encapsulation and protocol header, is defined by RFC 791. The e= volution of Internet communications have led to continued development in th= is area, encapsulated in the development of version 6 of the protocol in RF= C 2460. In spite of this updated protocol, we find that 25 years after the = specification of version 6 of the protocol, the older v4 standard continues= to account for a sizable majority of internet traffic.

The internet was designed as a platform for free and open communicati= on, most notably encoded in the end-to-end principle, and that philosophy i= s also present in the technical implementation of the Internet Protocol. [1= ] While the protocol was designed to exist in an environment where intellig= ence is at the end hosts, it has proven to provide sufficient information t= hat a more intelligent network core can make policy decisions and enforce p= olicy shaping and restricting the communications of end hosts. These capabi= lities for network control and limitations of the freedom of expression by = end hosts can be traced back to the IPv4 design, helping us understand whic= h technical protocol decisions have led to harm of these human rights.

Two major shifts have occurred to harm freedom of expr= ession through misuse of the Internet Protocol. The first is the network=E2= =80=99s exploitation of the public visibility of the host pairs for all com= munications, and the corresponding ability to discriminate and block traffi= c as a result of that metadata. The second is the selective development of = IP options, so that protocol extensions promoting assembly and expression l= ike Mobility and Multicasting can fail to receive support from IP compatibl= e devices. This lack of forward compatibility where extensions can receive = a baseline level of support needed to extend the design has stymied forms o= f expression which could have been extended to support these human rights.<= /div>


Networ= k visibility of Source and Destination
-----
The IPv4 p= rotocol header contains fixed location fields for both the source and desti= nation IP addresses [1]. These addresses identify both the host sending and= receiving each message, and allow the core network to understand who is ta= lking to whom, and to practically limit communication selectively between p= airs of hosts. Blocking of communication based on the pair of source and de= stination is one of the most common limitations on the ability for hosts to= communicate today, [2] and can be seen as a restriction of the ability for= those hosts to assemble or to consensually express themselves.
<= br>
We have seen from other instantiations of protocols, even tho= se comparable to IPv4, that other designs are possible. IPv4 even encodes a= defined option and specification for source routing of packets, where the = source can specify or suggest a routing path, and as the message passes thr= ough those paths, the part of the path it has completed are removed from th= e path. This design has the potential to make it much more difficult for an= individual router in the network to stifle speech, since it will cannot do= the same level of differentiation on the source of the messages.=C2=A0 Unf= ortunately, many networks prevent the use of source routing, and the protoc= ol is not designed such that support of that ability is required in order f= or the protocol to be implemented.

Documentation o= f this form of harm:

Protocols
----= -
The other major feature of the IP protocol header is that it sp= ecifies the protocol encapsulated in each message in an easily observable f= orm, and does not encourage a design where the encapsulated protocol is not= available to a network observer.=C2=A0 This design has resulted in a proli= feration of routers which inspect the inner protocol, and has resulted in a= stagnation where only the TCP and UDP protocols are widely supported acros= s the Internet. While the IP protocol was designed as the entire set of met= adata needed for routing, subsequent enhanced routers have found value on m= aking policy decisions based on the contents of TCP and UDP headers as well= , and are encoded with the assumption that only these protocols will be use= d for data transfer. [1] This has prevented development of more secure prot= ocols, since there=E2=80=99s a need to provide sufficient metadata with eac= h message for routers to make positive policy decisions if you hope the pro= tocol will be available to all users.

Documentatio= n of this form of harm:
[1] https://www.chromium.org/spdy/spdy-whitepaper

Address Tran= slation and Mobility
-----
A major structural shift in = the Internet which has undermined the protocol design of IPv4, and has sign= ificantly reduced the freedom of end users to communicate and assemble in t= he introduction network address translation. [1] Network address translatio= n is a process whereby organizations and autonomous systems to connect two = networks by translating the IPv4 source and destination addresses between t= he two. This process puts the router performing the translation into a priv= ileged position, where it can decide which subset of communications are wor= thy of translation, and whether an unknown request for communication will b= e correctly forwarded to a host on the other network.

<= div>This process of translation has widespread adoption despite promoting a= process that goes against the stated end-to-end process of the underlying = protocol [2]. In contrast, the proposed mechanism to provide support for mo= bility and forwarding to clients which may move, encoded instead as an opti= on in the IP protocol [3], has failed to gain traction. This situation agai= n suggests that the compromise made in design of the protocol has resulted = in a technology which failed to technical encode the freedom of expression = goals it was designed to promote.

Documentation of= this form of harm:
--001a1134bae0ec06520521b0257f-- From nobody Sat Oct 10 06:52:37 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2232E1B33AF for ; Sat, 10 Oct 2015 06:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA-ZDciI1r9s for ; Sat, 10 Oct 2015 06:52:33 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7301B33AE for ; Sat, 10 Oct 2015 06:52:33 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t9ADqVvB009061 for ; Sat, 10 Oct 2015 09:52:31 -0400 Received: (qmail 3181 invoked by uid 0); 10 Oct 2015 13:52:31 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 10 Oct 2015 13:52:30 -0000 References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> To: hrpc@irtf.org From: Avri Doria X-Enigmail-Draft-Status: N1110 Organization: Technicalities Message-ID: <5619181C.5090404@acm.org> Date: Sat, 10 Oct 2015 09:52:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151007111244.GA29746@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 151010-0, 10/10/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 13:52:35 -0000 On 07-Oct-15 07:12, Stephane Bortzmeyer wrote: > As I said, it is one of the best > kept secrets of Internet governance. The professionals of the > governance circus typically ignore this issue (too practical? too > difficult?). I am not sure it is either a secret of has always been ignored. I remember it being discussed as far back as the working Group on Internet Goverance (WGIG) in 2005. The WGIG Report says the following: > Lack of formal relationship with root server operators. > The root zone operators perform their functions today without a > formal relationship with any authority. The WGIG Background report also contains a discussion, though not as explicit as yours. There have been other references over the years in various Internet Governance Forum (IGF) and other discussions. Over the years there have been many discussions in the various Internet governance venues of the fact that root server operators are each independent operators, who do what they do based on their own decisions with loose informal coordination among themselves. This notion of informal coordination is central to much of the technical management of the Internet. There are those who have wanted to find a way to add international governance to that, but up to now that has remained a non starter. As you say, it may be too difficult. There have also been some discussions over the years questioning whether DNSSEC in some sense bound these root server a bit more as it removed some of their discretion about which records they accepted, providing a technical measure of coordination. I am not making a normative statement at this point about whether this independence and the DNSSEC are helpful or not to freedom of expression and association, but just trying to argue that is not quite as deep and dark a secret among the 'circus' professionals as presented. I do agree that getting Internet governance of the root server operators does not seem to be a current work item - root servers are not even mentioned in the early drafts of WSIS+10 paper the UN General Assembly will be approving at the end of the year. I am also sure that many of the participants in Internet governance know nothing about this, but it isn't a dark secret and it has been discussed over the years. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Sat Oct 10 09:53:54 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77C1B4108 for ; Sat, 10 Oct 2015 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omBWMvDfYalO for ; Sat, 10 Oct 2015 09:53:51 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A4C1B4106 for ; Sat, 10 Oct 2015 09:53:50 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so53683500igc.1 for ; Sat, 10 Oct 2015 09:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZsXvuYtqvTBxNRfpXP86nx7Qz2MPR0icl9gxD3+5fvw=; b=fCpFQC+EiHOguvIuxkKWpgWPrObW9Kckdkp3tF28s2QAJfjso9IzZXH4T8g3pYlaX8 2oRyk63/d7p3j5GNts9n0fsXaegR9O1s+nO8tzA78/0yDK0Am5C7hE41KOt3IysBTQhq GJIYYN2z1JTWHaASfFgSIcR4dNithTozkV//g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZsXvuYtqvTBxNRfpXP86nx7Qz2MPR0icl9gxD3+5fvw=; b=DuaAiCvCn83leMn+5adSk3rY0FSE/DLv1TMqrvpLpH8LRWk86r1wKJn+Es7Qp4n4kL W+gx4L7t4jU0L4dpxYKdPR5O0WTxQQBdei/p7b0wUs+EwS2fnX1z9GLFEwgCTsJzE96S qyslPhn7JTbqYJKzsM//WPlhTTNhP3Qu4hbDV+UumwunnFtCSr22Zkzh3WFI8QtYKlDP msF0FFQBCVoBE8JfldqoYArBa3+4xRpDmeESjrk/f3/admMsaeHvGpaV7Sonhvpw2q4n RQUq4tELI0gpiaDYNY5ETXVcMzOV0Kj3ia0WwlIj9xh/H0c+OlXgCJ87mJ51Qk7yOWVc 8QIg== X-Gm-Message-State: ALoCoQkSr12e7642WiskAUjxPm/yPYKTK783Eys6ir4FMDXbNH1jHLZOmRrb1uJ6iwoAbglor4Ru MIME-Version: 1.0 X-Received: by 10.50.73.71 with SMTP id j7mr4886762igv.28.1444496030270; Sat, 10 Oct 2015 09:53:50 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Sat, 10 Oct 2015 09:53:50 -0700 (PDT) In-Reply-To: <5619181C.5090404@acm.org> References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> <5619181C.5090404@acm.org> Date: Sat, 10 Oct 2015 09:53:50 -0700 Message-ID: From: Will Scott To: avri@acm.org Content-Type: multipart/alternative; boundary=089e013a0272c3a5930521c2f040 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 16:53:52 -0000 --089e013a0272c3a5930521c2f040 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for all the feedback. I'm working through updating the the first draft, and will drop root server discussion and will do some more diligence at living in our modern dnssec world. Injection of records, as in the case of China, does seem to be one of the major attacks that the protocol has historically (and in practice continues) to be vulnerable to; despite being mitigated by DNSSEC. I'd be interested in input in how that might be most effectively framed. Andrew seems to suggest the injection section is hard to justify from the protocol, and hurts the argument. Is there consensus that it should be dropped? --Will On Sat, Oct 10, 2015 at 6:52 AM, Avri Doria wrote: > > > On 07-Oct-15 07:12, Stephane Bortzmeyer wrote: > > As I said, it is one of the best > > kept secrets of Internet governance. The professionals of the > > governance circus typically ignore this issue (too practical? too > > difficult?). > > I am not sure it is either a secret of has always been ignored. I > remember it being discussed as far back as the working Group on Internet > Goverance (WGIG) in 2005. The WGIG Report says the following: > > Lack of formal relationship with root server operators. > > =E2=80=A2 The root zone operators perform their functions today without= a > > formal relationship with any authority. > > The WGIG Background report also contains a discussion, though not as > explicit as yours. There have been other references over the years in > various Internet Governance Forum (IGF) and other discussions. > > Over the years there have been many discussions in the various Internet > governance venues of the fact that root server operators are each > independent operators, who do what they do based on their own decisions > with loose informal coordination among themselves. This notion of > informal coordination is central to much of the technical management of > the Internet. There are those who have wanted to find a way to add > international governance to that, but up to now that has remained a non > starter. As you say, it may be too difficult. > > There have also been some discussions over the years questioning whether > DNSSEC in some sense bound these root server a bit more as it removed > some of their discretion about which records they accepted, providing a > technical measure of coordination. > > I am not making a normative statement at this point about whether this > independence and the DNSSEC are helpful or not to freedom of expression > and association, but just trying to argue that is not quite as deep and > dark a secret among the 'circus' professionals as presented. I do agree > that getting Internet governance of the root server operators does not > seem to be a current work item - root servers are not even mentioned in > the early drafts of WSIS+10 paper the UN General Assembly will be > approving at the end of the year. I am also sure that many of the > participants in Internet governance know nothing about this, but it > isn't a dark secret and it has been discussed over the years. > > avri > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --089e013a0272c3a5930521c2f040 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for all the feedback. I'm working through updat= ing the the first draft, and will drop root server discussion and will do s= ome more diligence at living in our modern dnssec world.

Injection of records, as in the case of China, does seem to be one of the = major attacks that the protocol has historically (and in practice continues= ) to be vulnerable to; despite being mitigated by DNSSEC.=C2=A0 I'd be = interested in input in how that might be most effectively framed. Andrew se= ems to suggest the injection section is hard to justify from the protocol, = and hurts the argument. Is there consensus that it should be dropped?
=

--Will


On Sat, Oct 10, 2015 at 6:52 AM, Avri D= oria <avri@acm.org> wrote:


On 07-Oct-15 07:12, Stephane Bortzmeyer wrote:
>=C2=A0 As I said, it is one of the best
> kept secrets of Internet governance. The professionals of the
> governance circus typically ignore this issue (too practical? too
> difficult?).

I am not sure it is either a secret of has always been ignored.=C2= =A0 I
remember it being discussed as far back as the working Group on Internet Goverance (WGIG) in 2005. The WGIG Report says the following:
> Lack of formal relationship with root server operators.
> =E2=80=A2 The root zone operators perform their functions today withou= t a
> formal relationship with any authority.

The WGIG Background report also contains a discussion, though not as
explicit as yours. There have been other references over the years in
various Internet Governance Forum (IGF) and other discussions.

Over the years there have been many discussions in the various Internet
governance venues of the fact that root server operators are each
independent operators,=C2=A0 who do what they do based on their own decisio= ns
with loose informal coordination among themselves. This notion of
informal coordination is central to much of the technical management of
the Internet.=C2=A0 There are those who have wanted to find a way to add international governance to that, but up to now that has remained a non
starter. As you say, it may be too difficult.

There have also been some discussions over the years questioning whether DNSSEC in some sense bound these root server a bit more as it removed
some of their=C2=A0 discretion about which records they accepted, providing= a
technical measure of coordination.

I am not making a normative statement at this point about whether this
independence and the DNSSEC are helpful or not to freedom of expression
and association, but just trying to argue that is not quite as=C2=A0 deep a= nd
dark a secret among the 'circus' professionals as presented.=C2=A0 = I do agree
that getting Internet governance of the root server operators does not
seem to be a current work item - root servers are not even mentioned in
the early drafts of=C2=A0 WSIS+10 paper the UN General Assembly will be
approving at the end of the year.=C2=A0 I am also sure that many of the
participants in Internet governance know nothing about this, but it
isn't a dark secret and it has been discussed over the years.

avri







---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

--089e013a0272c3a5930521c2f040-- From nobody Sat Oct 10 17:46:09 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE01B4B27 for ; Sat, 10 Oct 2015 17:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isO2HbrtdcEI for ; Sat, 10 Oct 2015 17:46:04 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF381B4B25 for ; Sat, 10 Oct 2015 17:46:04 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 2CB3DC5A3C for ; Sun, 11 Oct 2015 02:46:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lXeBvsNCjotU for ; Sun, 11 Oct 2015 02:46:00 +0200 (CEST) X-Originating-IP: 95.91.242.79 Received: from [192.168.1.105] (unknown [95.91.242.79]) (Authenticated sender: lists@nex.sx) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 6C480C5A37 for ; Sun, 11 Oct 2015 02:45:59 +0200 (CEST) To: hrpc@irtf.org From: Nex Message-ID: <5619B147.3040603@nex.sx> Date: Sun, 11 Oct 2015 02:45:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 00:46:08 -0000 Hello everybody. Here are some initial considerations on P2P networks. This is a complex one to address as implementations and use cases vary so much. I'm sure it needs to be expanded upon, but this could a starting point. PEER-TO-PEER Introduction Peer-to-Peer (P2P) is a network architecture (defined in RFC7574) in which all the participant nodes are equally responsible engaged into the storage and dissemination of information. A P2P network is a logical overlay that lives on top of the physical network, and allows nodes (or "peers") participating to it to establish contact and exchange information directly from one to each other. The implementation of a P2P network may very widely: it may be structured or unstructured, and it may implement stronger or weaker cryptographic and anonymity properties. While its most common application has traditionally been file-sharing (and other types of content delivery systems), P2P is increasingly becoming a popular architecture for networks and applications that require (or encourage) decentralization. A prime example is Bitcoin (and similar cryptocurrencies), as well as Skype, Spotify and other proprietary multimedia applications. In a time of heavily centralized online services, peer-to-peer is often seen as an alternative, more democratic, and resistant architecture that displaces structures of control over data and communications and delegates all peers equally to be responsible for the functioning, integrity, and security of the data. While in principle peer-to-peer remains critical to the design and development of future content distribution, messaging, and publishing systems, it poses numerous security and privacy challenges which are mostly delegated to individual developers to recognize, analyze, and solve in each implementation of a given P2P network. Network Poisoning Since content, and in some occasions peer lists, are safeguarded and distributed by its members, P2P networks are prone to what are generally defined as "poisoning attacks". Poisoning attacks might be directed directly at the data that is being distributed, for example by intentionally corrupting it, or at the index tables used to instruct the peers where to fetch the data, or at routing tables, with the attempt of providing connecting peers with lists of rogue or non-existing peers, with the intention to effectively cause a Denial of Service on the network. Throttling Peer-to-Peer traffic (and BitTorrent in particular) represents a high percentage of global Internet traffic and it has become increasingly popular for Internet Service Providers to perform throttling of customers lines in order to limit bandwidth usage[1] and sometimes probably as an effect of the ongoing conflict between copyright holders and file-sharing communities[2]. Throttling the peer-to-peer traffic makes some uses of P2P networks ineffective and it might be coupled with stricter inspection of users' Internet traffic through Deep Packet Inspection techniques which might pose additional security and privacy risks. Tracking and Identification One of the fundamental and most problematic issues with traditional peer-to-peer networks is a complete lack of anonymization of its users. For example, in the case of BitTorrent, all peers' IP addresses are openly available to the other peers. This has lead to an ever-increasing tracking of peer-to-peer and file-sharing users[3]. As the geographical location of the user is directly exposed, and so could be his identity, the user might become target of additional harassment and attacks, being of physical or legal nature. For example, it is known that in Germany lawfirms have made extensive use of peer-to-peer and file-sharing tracking systems in order to identify downloaders and initiate legal actions looking for compensations[4]. It is worth nothing that there are varieties of P2P networks that implement cryptographic practices and that introduce anonymization of its users. Such implementations proved to be successful in resisting censorship of content, and tracking of the network peers. A primary example is FreeNet[5], a free software application designed to significantly increase the difficulty of users and content identification, and dedicated to foster freedom of speech online[6]. Conclusions Encrypted P2P and Anonymous P2P networks already emerged and provided viable platforms for sharing material, publish content anonymously, and communicate securely[7]. If adopted at large, well-designed and resistant P2P networks might represent a critical component of a future secure and distributed Internet, enabling freedom of speech and freedom of information at scale. [1] https://torrentfreak.com/is-your-isp-messing-with-bittorrent-traffic-find-out-140123/ [2] https://wikileaks.org/sony/docs/05/docs/Anti-Piracy/CDSA/EANTC-Survey-1.5-unsecured.pdf [3] http://arstechnica.com/uncategorized/2007/10/p2p-researchers-use-a-blocklist-or-you-will-be-tracked-100-of-the-time/ [4] https://torrentfreak.com/lawyers-sent-109000-piracy-threats-in-germany-during-2013-140304/ [5] https://freenetproject.org/whatis.html [6] https://freenetproject.org/philosophy.html [7] https://bitmessage.org/wiki/Main_Page From nobody Sat Oct 10 21:06:30 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370F1ACE50 for ; Sat, 10 Oct 2015 21:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAbrggsdbh3p for ; Sat, 10 Oct 2015 21:06:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0601ACE49 for ; Sat, 10 Oct 2015 21:06:27 -0700 (PDT) Received: from [192.168.0.18] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB75822E261; Sun, 11 Oct 2015 00:06:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <5619B147.3040603@nex.sx> Date: Sun, 11 Oct 2015 15:06:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <37EF209C-E897-4721-88B2-FCD4E66A4651@mnot.net> References: <5619B147.3040603@nex.sx> To: Nex X-Mailer: Apple Mail (2.2104) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 04:06:30 -0000 Hi, On 11 Oct 2015, at 11:45 am, Nex wrote: >=20 > Tracking and Identification >=20 > One of the fundamental and most problematic issues with traditional > peer-to-peer networks is a complete lack of anonymization of its = users. > For example, in the case of BitTorrent, all peers' IP addresses are > openly available to the other peers. This has lead to an = ever-increasing > tracking of peer-to-peer and file-sharing users[3]. As the = geographical > location of the user is directly exposed, and so could be his = identity, > the user might become target of additional harassment and attacks, = being > of physical or legal nature. For example, it is known that in Germany > lawfirms have made extensive use of peer-to-peer and file-sharing > tracking systems in order to identify downloaders and initiate legal > actions looking for compensations[4]. >=20 > It is worth nothing that there are varieties of P2P networks that > implement cryptographic practices and that introduce anonymization of > its users. Such implementations proved to be successful in resisting > censorship of content, and tracking of the network peers. A primary > example is FreeNet[5], a free software application designed to > significantly increase the difficulty of users and content > identification, and dedicated to foster freedom of speech online[6]. I think there's an important aspect here that deserves highlighting; not = only is lack of anonymity an issue, but also the privacy of the user's = activity is extremely difficult to protect. That's because fundamentally, you have to ask your peers for content by = some identifier, and they can use that identifier to discover what = you're requesting. Freenode admits as such [1] Private Information Retrieval theoretically can avoid this, but AFAIK = this isn't implemented in any P2P system, nor is it likely to be soon, = due to the technical challenges (would be VERY happy to be proven wrong = on this point). Of course, this isn't an issue if you implicitly trust your peers; = however, that doesn't seem a very good assumption to make for human = rights considerations... Cheers, 1. https://freenetproject.org/faq.html#hash =20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Oct 11 09:21:57 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7D41A0204 for ; Sun, 11 Oct 2015 09:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 837MPsWgRirK for ; Sun, 11 Oct 2015 09:21:54 -0700 (PDT) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id D08EC1A01FA for ; Sun, 11 Oct 2015 09:21:53 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t9BGLoHk008616 for ; Sun, 11 Oct 2015 12:21:50 -0400 Received: (qmail 21875 invoked by uid 0); 11 Oct 2015 16:21:50 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 11 Oct 2015 16:21:50 -0000 References: <5619B147.3040603@nex.sx> To: hrpc@irtf.org From: Avri Doria Organization: Technicalities Message-ID: <561A8C9B.6070707@acm.org> Date: Sun, 11 Oct 2015 12:21:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5619B147.3040603@nex.sx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 151011-0, 10/11/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 16:21:56 -0000 Hi, Thanks for this contribution. A question on throttling: while used extensively against BitTorrent, I think that it would be a broader issue. >From reading the use cases, I have begun to think that there is much as case to made for some of the combinatorial effects of protocols as well as the effect of the individual protocols. avri On 10-Oct-15 20:45, Nex wrote: > Hello everybody. > Here are some initial considerations on P2P networks. This is a complex > one to address as implementations and use cases vary so much. I'm sure > it needs to be expanded upon, but this could a starting point. > > > > > PEER-TO-PEER > > > Introduction > > Peer-to-Peer (P2P) is a network architecture (defined in RFC7574) in > which all the participant nodes are equally responsible engaged into the > storage and dissemination of information. A P2P network is a logical > overlay that lives on top of the physical network, and allows nodes (or > "peers") participating to it to establish contact and exchange > information directly from one to each other. The implementation of a P2P > network may very widely: it may be structured or unstructured, and it > may implement stronger or weaker cryptographic and anonymity properties. > While its most common application has traditionally been file-sharing > (and other types of content delivery systems), P2P is increasingly > becoming a popular architecture for networks and applications that > require (or encourage) decentralization. A prime example is Bitcoin (and > similar cryptocurrencies), as well as Skype, Spotify and other > proprietary multimedia applications. > > In a time of heavily centralized online services, peer-to-peer is often > seen as an alternative, more democratic, and resistant architecture that > displaces structures of control over data and communications and > delegates all peers equally to be responsible for the functioning, > integrity, and security of the data. While in principle peer-to-peer > remains critical to the design and development of future content > distribution, messaging, and publishing systems, it poses numerous > security and privacy challenges which are mostly delegated to individual > developers to recognize, analyze, and solve in each implementation of a > given P2P network. > > > Network Poisoning > > Since content, and in some occasions peer lists, are safeguarded and > distributed by its members, P2P networks are prone to what are generally > defined as "poisoning attacks". Poisoning attacks might be directed > directly at the data that is being distributed, for example by > intentionally corrupting it, or at the index tables used to instruct the > peers where to fetch the data, or at routing tables, with the attempt of > providing connecting peers with lists of rogue or non-existing peers, > with the intention to effectively cause a Denial of Service on the network. > > > Throttling > > Peer-to-Peer traffic (and BitTorrent in particular) represents a high > percentage of global Internet traffic and it has become increasingly > popular for Internet Service Providers to perform throttling of > customers lines in order to limit bandwidth usage[1] and sometimes > probably as an effect of the ongoing conflict between copyright holders > and file-sharing communities[2]. > > Throttling the peer-to-peer traffic makes some uses of P2P networks > ineffective and it might be coupled with stricter inspection of users' > Internet traffic through Deep Packet Inspection techniques which might > pose additional security and privacy risks. > > > Tracking and Identification > > One of the fundamental and most problematic issues with traditional > peer-to-peer networks is a complete lack of anonymization of its users. > For example, in the case of BitTorrent, all peers' IP addresses are > openly available to the other peers. This has lead to an ever-increasing > tracking of peer-to-peer and file-sharing users[3]. As the geographical > location of the user is directly exposed, and so could be his identity, > the user might become target of additional harassment and attacks, being > of physical or legal nature. For example, it is known that in Germany > lawfirms have made extensive use of peer-to-peer and file-sharing > tracking systems in order to identify downloaders and initiate legal > actions looking for compensations[4]. > > It is worth nothing that there are varieties of P2P networks that > implement cryptographic practices and that introduce anonymization of > its users. Such implementations proved to be successful in resisting > censorship of content, and tracking of the network peers. A primary > example is FreeNet[5], a free software application designed to > significantly increase the difficulty of users and content > identification, and dedicated to foster freedom of speech online[6]. > > > Conclusions > > Encrypted P2P and Anonymous P2P networks already emerged and provided > viable platforms for sharing material, publish content anonymously, and > communicate securely[7]. If adopted at large, well-designed and > resistant P2P networks might represent a critical component of a future > secure and distributed Internet, enabling freedom of speech and freedom > of information at scale. > > > [1] > https://torrentfreak.com/is-your-isp-messing-with-bittorrent-traffic-find-out-140123/ > [2] > https://wikileaks.org/sony/docs/05/docs/Anti-Piracy/CDSA/EANTC-Survey-1.5-unsecured.pdf > [3] > http://arstechnica.com/uncategorized/2007/10/p2p-researchers-use-a-blocklist-or-you-will-be-tracked-100-of-the-time/ > [4] > https://torrentfreak.com/lawyers-sent-109000-piracy-threats-in-germany-during-2013-140304/ > [5] https://freenetproject.org/whatis.html > [6] https://freenetproject.org/philosophy.html > [7] https://bitmessage.org/wiki/Main_Page > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Mon Oct 12 03:22:24 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E81ACCE8 for ; Mon, 12 Oct 2015 03:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBMIGAucVOOW for ; Mon, 12 Oct 2015 03:22:22 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB07B1ACCE5 for ; Mon, 12 Oct 2015 03:22:21 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E3FF7280347; Mon, 12 Oct 2015 12:22:19 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id DE9BB2802AC; Mon, 12 Oct 2015 12:22:19 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id D2FBEB38024; Mon, 12 Oct 2015 12:21:49 +0200 (CEST) Date: Mon, 12 Oct 2015 12:21:49 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151012102149.GA2465@nic.fr> References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> <56150622.9000101@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56150622.9000101@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= , Stephane Bortzmeyer , "hrpc@irtf.org" Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 10:22:23 -0000 On Wed, Oct 07, 2015 at 01:46:42PM +0200, Niels ten Oever wrote a message of 71 lines which said: > This is how I understand it, You talk about the management of the root database, I was talking about the management of root name servers, it's very different (for instance, ICANN has a role in the first one, not in the second). > Question from my side: were there ever any discrepancies between the > root servers, other than those caused by a time lag? http://masonlee.org/2009/12/18/dns-takeover-1998/ From nobody Mon Oct 12 03:27:53 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4A1ACD0C for ; Mon, 12 Oct 2015 03:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3tF1k4YX7hg for ; Mon, 12 Oct 2015 03:27:51 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0B01ACD0B for ; Mon, 12 Oct 2015 03:27:51 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E938E280348; Mon, 12 Oct 2015 12:27:49 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id E2FCD280347; Mon, 12 Oct 2015 12:27:49 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id D7B8CB38026; Mon, 12 Oct 2015 12:27:19 +0200 (CEST) Date: Mon, 12 Oct 2015 12:27:19 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151012102719.GB2465@nic.fr> References: <561524CE.2090902@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561524CE.2090902@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] cases - HTTP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 10:27:52 -0000 On Wed, Oct 07, 2015 at 03:57:34PM +0200, Niels ten Oever wrote a message of 217 lines which said: > The Hypertext Transfer Protocol (HTTP), described in its version 1.1 > in RFC2616, No, RFC 7230 to 7237. Otherwise, nice text, no remarks. From nobody Mon Oct 12 04:38:14 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED351ACE89 for ; Mon, 12 Oct 2015 04:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYIMZRB0fYxQ for ; Mon, 12 Oct 2015 04:38:11 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819841ACE91 for ; Mon, 12 Oct 2015 04:38:11 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 8552F28027B; Mon, 12 Oct 2015 13:38:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 771A12801F8; Mon, 12 Oct 2015 13:38:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 740C9B3800C; Mon, 12 Oct 2015 13:37:39 +0200 (CEST) Date: Mon, 12 Oct 2015 13:37:39 +0200 From: Stephane Bortzmeyer To: Will Scott Message-ID: <20151012113739.GC2465@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases - XMPP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 11:38:13 -0000 On Wed, Oct 07, 2015 at 08:42:48AM -0700, Will Scott wrote a message of 241 lines which said: > The Extensible Messaging and Presence Protocol (XMPP), specified in RFC > 3920, No, 6120. > a lack of protocol specification of the registration policy, It is a feature, not a bug: every server has its own policy (from "no registration allowed" on IETF XMPP server, to very lax). > The XMPP specification specifies that clients are identified with a > resource ( / ) to distinguish > the conversations to specific devices. This has the side effect of > enabling tracking of user behavior Nothing mandates that the resource is a location, or that it is understandable from the outide (the relevant RFC is RFC 7622, section 3.4). It is true that resources like "home" or "work" appear often in the documentations and even in some RFC. A possible improvment would be a privacy considerations section in the successor of RFC 7622, warning of this risk. > In practice, this leads to cases where text encoded outside of a > standard english language ascii encoding will fail to render on all > clients, I do not see the relationship between this problem and the UTF-8 vs. UTF-16 issue. > Some examples are failure of XMPP servers to handle non-ascii > passwords [3], Certainly, the users want to communicate in their own script (not language: IETF protocols don't know languages). But it is less evident that they want passwords in Unicode (see RFC 7613). I would say it is a problem but a much less severe one. > and gateways which simply strip all non-ascii from the conversation > stream. Gateways between protocols are notorious for mangling. It is unfair to blame it on XMPP. > the lack of actual implementation of the more extensible character > set by all clients has shaped the protocol to harm the full range of > expression users may desire. I'm not sure I understand this sentence (UTF-16 is certainly not "more extensible"). If I do, it makes no sense to me, since UTF-8 and UTF-16 can encode exactly the same character set (Unicode). > The XMPP protocol specifies the standard by which communication of > channels may be encrypted, but it does not provide visibility to > clients of whether their communications are encrypted on each link. This, and the fact that there is no standard end-to-end encryption, meaning that a rogue server knows the conversation. This could be a place to mention OTR (and to note it is poorly integrated in XMPP). From nobody Mon Oct 12 05:00:39 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC41ACF09 for ; Mon, 12 Oct 2015 05:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAQ2zaz1xRWy for ; Mon, 12 Oct 2015 05:00:36 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F281ACF18 for ; Mon, 12 Oct 2015 05:00:35 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 341FD19C002 for ; Mon, 12 Oct 2015 12:00:34 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2410B19C003 for ; Mon, 12 Oct 2015 12:00:34 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 1904A19C002 for ; Mon, 12 Oct 2015 12:00:34 +0000 (UTC) Message-ID: <561BA0E1.3070702@article19.org> Date: Mon, 12 Oct 2015 14:00:33 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: hrpc@irtf.org References: <20151012113739.GC2465@nic.fr> In-Reply-To: <20151012113739.GC2465@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] cases - XMPP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:00:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > This, and the fact that there is no standard end-to-end > encryption, meaning that a rogue server knows the conversation. > > This could be a place to mention OTR (and to note it is poorly > integrated in XMPP). > As well as the lack of the opportunity for secure multi party encryption / messaging with XMPP + OTR. https://www.ietf.org/blog/tag/otr/ Best, Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG6DhAAoJEAi1oPJjbWjpthcH/0ogRSQ3LM06D2UPzcnjh3PW CGNXSKwodvS58AaPqgFqipZ2qLVi3s+ISSPvKuS3rHftZ4G0fPO4nUqnwLrJnP+5 aDEMqT4jtx1vRHJiSh48Vei6WtSz//odlBfYkyZ1PaIlZPpyNWdVOHuYwQITjBeH scaRXkDDJW8n8JFcWuvqDarSPqYAHxTHCmc/+BNEWBSnRPXdq1TOA6epdu0Uq7dd VR27c1ps1uut7TJ6Bo3qNrNoUWM3vpQ/vN4uqEnA/8G1HWiCHVBkwBdlppBv8/Ix FKiymzMo7uUfFjMjsXXSm/8wZTB7BZuzlnDfUirlMVaPt3oPvqu0hHhH1syKgHo= =nNa3 -----END PGP SIGNATURE----- From nobody Mon Oct 12 05:04:55 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8089A1AD067 for ; Mon, 12 Oct 2015 05:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH78jg4p4_ta for ; Mon, 12 Oct 2015 05:04:52 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5ABC1AD069 for ; Mon, 12 Oct 2015 05:04:52 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2A8FF28027B; Mon, 12 Oct 2015 14:04:51 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 2508B2801F8; Mon, 12 Oct 2015 14:04:51 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 223A4B38026; Mon, 12 Oct 2015 14:04:21 +0200 (CEST) Date: Mon, 12 Oct 2015 14:04:21 +0200 From: Stephane Bortzmeyer To: Will Scott Message-ID: <20151012120421.GD2465@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases - IP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:04:54 -0000 On Fri, Oct 09, 2015 at 11:28:37AM -0700, Will Scott wrote a message of 260 lines which said: > The second is the selective development of IP options, so that > protocol extensions promoting assembly and expression like Mobility > and Multicasting can fail to receive support from IP compatible > devices. Strong disagreement here. Not on the unfortunate state of IP options (we agree here) but on the fact that IP mobility or multicasting enable "assembly and expression". I fear you go to far in technical determinism here. IP mobility, first. Technically, it is a bad idea from the beginning, assuming layer has to handle mobility. Actually, most of the time, mobility is better managed by applications (Pidgin for IM, all Twitter clients for Twitter, all email clients, rsync and BitTorrent nodes for file transfer, mosh for ssh, etc). Multicasting, second. Again, a bad idea from the beginning: multicasting is only beneficial when everybody access the same content at the very same time. Except religious ceremonies like the SuperBowl, it is less and less common. Most interactions are not synchronous and therefore do not depend on multicasting. > IPv4 even encodes a defined option and specification for source > routing of packets, where the source can specify or suggest a > routing path, and as the message passes through those paths, the > part of the path it has completed are removed from the path. This > design has the potential to make it much more difficult for an > individual router in the network to stifle speech, You lost me here. Filtering based on the pair source<->destination is most of the time done by a router which is close from the two communicating machines. Source routing wouldn't help since you have no choice of the edge routers. In countries where there is widespread IP address filtering, there are only a few communcation points with the outside and, again source routing would not help. A better solution, Tor, does not depend on source routing. > Unfortunately, many networks prevent the use of source routing, They are absolutely right, given the security risks of source routing. > The other major feature of the IP protocol header is that it > specifies the protocol encapsulated in each message in an easily > observable form, and does not encourage a design where the > encapsulated protocol is not available to a network observer. There is an IETF-sanctioned solution, ESP. Little deployment, I know. But any encrypting tunnel can do the same. From nobody Mon Oct 12 05:12:44 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5281A87ED for ; Mon, 12 Oct 2015 05:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.124 X-Spam-Level: *** X-Spam-Status: No, score=3.124 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr76aSBzmMow for ; Mon, 12 Oct 2015 05:12:41 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F901AD060 for ; Mon, 12 Oct 2015 05:12:41 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 437AD19C002 for ; Mon, 12 Oct 2015 12:12:40 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3371419C003 for ; Mon, 12 Oct 2015 12:12:40 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 27CBB19C002 for ; Mon, 12 Oct 2015 12:12:40 +0000 (UTC) Message-ID: <561BA3B7.8030907@article19.org> Date: Mon, 12 Oct 2015 14:12:39 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: hrpc@irtf.org References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> <5619181C.5090404@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:12:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Will, Since it is the most prevalent attack, I do not think it should be dropped, but it should be shown this is mitigated by the use of DNSSEC. However DNSSEC is not mandatory, so the the protocol still allows for this vulnerability imho. Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 10/10/2015 06:53 PM, Will Scott wrote: > Thanks for all the feedback. I'm working through updating the the > first draft, and will drop root server discussion and will do some > more diligence at living in our modern dnssec world. > > Injection of records, as in the case of China, does seem to be one > of the major attacks that the protocol has historically (and in > practice continues) to be vulnerable to; despite being mitigated by > DNSSEC. I'd be interested in input in how that might be most > effectively framed. Andrew seems to suggest the injection section > is hard to justify from the protocol, and hurts the argument. Is > there consensus that it should be dropped? > > --Will > > > On Sat, Oct 10, 2015 at 6:52 AM, Avri Doria > wrote: > > > > On 07-Oct-15 07:12, Stephane Bortzmeyer wrote: >> As I said, it is one of the best kept secrets of Internet >> governance. The professionals of the governance circus typically >> ignore this issue (too practical? too difficult?). > > I am not sure it is either a secret of has always been ignored. I > remember it being discussed as far back as the working Group on > Internet Goverance (WGIG) in 2005. The WGIG Report says the > following: >> Lack of formal relationship with root server operators. The >> root zone operators perform their functions today without a >> formal relationship with any authority. > > The WGIG Background report also contains a discussion, though not > as explicit as yours. There have been other references over the > years in various Internet Governance Forum (IGF) and other > discussions. > > Over the years there have been many discussions in the various > Internet governance venues of the fact that root server operators > are each independent operators, who do what they do based on their > own decisions with loose informal coordination among themselves. > This notion of informal coordination is central to much of the > technical management of the Internet. There are those who have > wanted to find a way to add international governance to that, but > up to now that has remained a non starter. As you say, it may be > too difficult. > > There have also been some discussions over the years questioning > whether DNSSEC in some sense bound these root server a bit more as > it removed some of their discretion about which records they > accepted, providing a technical measure of coordination. > > I am not making a normative statement at this point about whether > this independence and the DNSSEC are helpful or not to freedom of > expression and association, but just trying to argue that is not > quite as deep and dark a secret among the 'circus' professionals > as presented. I do agree that getting Internet governance of the > root server operators does not seem to be a current work item - > root servers are not even mentioned in the early drafts of WSIS+10 > paper the UN General Assembly will be approving at the end of the > year. I am also sure that many of the participants in Internet > governance know nothing about this, but it isn't a dark secret and > it has been discussed over the years. > > avri > > > > > > > > --- This email has been checked for viruses by Avast antivirus > software. https://www.avast.com/antivirus > > _______________________________________________ hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > > > _______________________________________________ hrpc mailing list > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG6O3AAoJEAi1oPJjbWjpiXIH/0vonZjISozLnUa9Q5cocpo6 EGzmv2AWWsjhe34URPgh5DRvs9Yp9XI1DDbHbLihGUtfBhLsYXLOSU5Y5z0pAoDc JnQffhaWLUZgTIJPGQcqGbeKCTsudhsPcWnnu94XV2iSpysAOJyEphgnjrxWejoV qHkyLwgSb+Vcx54R25e0gc8IJ0g4PvHf/tIHkx/3oxrG7LpQ+M4VOwz/FA/E72De zpu4eEMQ4BRXbb7GkniR9qPip1eCCvb/HY9LD8SIZvXglRePTlEda9Ww3+92S60S 75lDfKrIw63weu3w5E+wDZgMVScOZ857yY+hCXNZ9l+2Sx/5cKslIY49I+WXMN0= =UUS6 -----END PGP SIGNATURE----- From nobody Mon Oct 12 05:33:42 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF01B29CA for ; Mon, 12 Oct 2015 05:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7_9M-AXyWOq for ; Mon, 12 Oct 2015 05:33:38 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F9D1B29C7 for ; Mon, 12 Oct 2015 05:33:01 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id AA4F8380073 for ; Mon, 12 Oct 2015 12:33:00 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 933F2380074 for ; Mon, 12 Oct 2015 12:33:00 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 7C814380073 for ; Mon, 12 Oct 2015 12:33:00 +0000 (UTC) Message-ID: <561BA87C.8080708@article19.org> Date: Mon, 12 Oct 2015 14:33:00 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" References: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> In-Reply-To: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [hrpc] Session confirmed - agenda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:33:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, I hope this email finds you well. Our session for the Yokohama meeting has been confirmed. I would like to invite suggestions for the agenda. What we have currently got: - - Beginning (5 min) Agenda Bashing Jabber scribe, note takers Notewell Introduction - - Status of proposed research group (5 min) - - Context of research (10 Min) - - Discussion of 'A Case Study of Coding Rights' (20 min) https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf - - Discussion of Methodology draft (20 min) Cases IP DNS HTTP P2P XMPP VPN Definitions Way forward - - Discussion of Glossary draft (10 min) - - Discussion of Guidelines draft (20 min) - - Open discussion other drafts, papers, ideas (20 min) - - Charter update status &c. (if necessary - 5 Min) - - Next steps (5 min) - - AOB I would very much like to invite other topics and presentations to be part of the agenda (perhaps the draft by Mark, or further work by the research group of Roland Bless). I'm very much looking forward to your ideas and suggestions. Best, Niels - -------- Forwarded Message -------- Subject: hrpc - Requested session has been scheduled for IETF 94 Date: Fri, 09 Oct 2015 18:28:50 -0700 From: IETF Secretariat To: niels@article19.org CC: lars@netapp.com, niels@article19.org, avri@acm.org Dear Niels Oever, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. hrpc Session 1 (1:30:00) Tuesday, Afternoon Session II 1520-1650 Room Name: Room 302 size: 150 --------------------------------------------- Request Information: - --------------------------------------------------------- Working Group Name: Proposed Human Rights Protocol Considerations Research Group Area Name: IRTF Session Requester: Niels Oever Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: saag Second Priority: httpbis Third Priority: ianaplan Special Requests: Preferably not on Friday, also no conflict with DNSOP and DNSPriv pls. - --------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG6h8AAoJEAi1oPJjbWjpvicH/iIhC7nWBlcJ0Gyeqjr/DLv/ fywN0EUTGOoCBmuJHEuSXir1T7xd8BD8N7/vj77DV93YQpxIt0si6FuKJFW8A8tW Zx7mTJxRTV3Ct4ymkBc42fQW49eh352YYoIfLAAWFbq31qpNBIHp24CO9OjkYY8A KzzxgdwzAmmYX2uDLKvM2B2YSF3MA21d5WAcPsA1y1vvOa8aw0WvXbEcnLqNqHp2 me/ohARdE6KHP45DuUbkMYwbW4Sa7pFwo0WFTP+awlIGH9RLpGIKejno9HR/b+ig w0M5bKbXCon67INEYdClLsL0cd1E8FrH8jvaheSXdI0rXIOaN8LtOvK5Bva49GE= =8OED -----END PGP SIGNATURE----- From nobody Mon Oct 12 05:41:43 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B391B2A0E for ; Mon, 12 Oct 2015 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8kOth61EXnm for ; Mon, 12 Oct 2015 05:41:41 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A021B2A1C for ; Mon, 12 Oct 2015 05:41:38 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 196C72802A6; Mon, 12 Oct 2015 14:41:37 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 149C4280200; Mon, 12 Oct 2015 14:41:37 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 090FBB38024; Mon, 12 Oct 2015 14:41:07 +0200 (CEST) Date: Mon, 12 Oct 2015 14:41:07 +0200 From: Stephane Bortzmeyer To: Mark Nottingham Message-ID: <20151012124106.GA16984@nic.fr> References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:41:41 -0000 On Thu, Oct 08, 2015 at 11:27:58AM +1100, Mark Nottingham wrote a message of 64 lines which said: > I'm not sure HPRC is the right place for this to end up; Very good text, very useful. IMHO, HRPC is a reasonable place (but do what you want). From nobody Mon Oct 12 05:46:48 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443871B29F7 for ; Mon, 12 Oct 2015 05:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJW0IcpRVVUT for ; Mon, 12 Oct 2015 05:46:45 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C361AD0A5 for ; Mon, 12 Oct 2015 05:46:45 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1747D2802AC; Mon, 12 Oct 2015 14:46:44 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 120F028027B; Mon, 12 Oct 2015 14:46:44 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 6D455B3800C; Mon, 12 Oct 2015 14:46:07 +0200 (CEST) Date: Mon, 12 Oct 2015 14:46:07 +0200 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20151012124607.GB16984@nic.fr> References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> <5615C028.4050506@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5615C028.4050506@cs.tcd.ie> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Mark Nottingham , hrpc@irtf.org Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:46:47 -0000 On Thu, Oct 08, 2015 at 02:00:24AM +0100, Stephen Farrell wrote a message of 142 lines which said: > - If end-users like something that's not really good for them > (e.g. handing over all their personal information to a few > mega-companies) then are we supposed to prioritise things based on > how they behave or how we think they ought behave? (Or even on how > we think we ought behave..) This is covered in the last paragraph of section 2. Choices like this one must be discussed (currently, "handing over all their personal information to a few mega-companies" is certainly not an informed decision taken after careful examination of the pros and cons). > - The set of identifiable parties doesn't only include those who > benefit from our standards, but also those who lose, e.g. hopefully > criminals and spooks will lose, but so will some companies with some > business models, and so will some sets of people. That can be > important when considering trade-offs in that the delta in outcome > for a losing class of persons may be a good, or a bad, thing. Criminals are stake-holders, too :-) > - I don't think the code-regulates quote is useful, personally I > find it problematic, and all you need to say is that the code that > implements RFCs has obvious impact I like it. What is problematic in it? > - It's somehow cute that you choose 6525 as an example of harm;-) You mean 6265? From nobody Mon Oct 12 05:53:47 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B911B2A52 for ; Mon, 12 Oct 2015 05:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQD9FahEhjOc for ; Mon, 12 Oct 2015 05:53:45 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149931B2A50 for ; Mon, 12 Oct 2015 05:53:45 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7ED0728027B; Mon, 12 Oct 2015 14:53:43 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 79E5C280200; Mon, 12 Oct 2015 14:53:43 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 6DF2EB3800C; Mon, 12 Oct 2015 14:53:13 +0200 (CEST) Date: Mon, 12 Oct 2015 14:53:13 +0200 From: Stephane Bortzmeyer To: Nex Message-ID: <20151012125313.GC16984@nic.fr> References: <5619B147.3040603@nex.sx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5619B147.3040603@nex.sx> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:53:46 -0000 On Sun, Oct 11, 2015 at 02:45:59AM +0200, Nex wrote a message of 116 lines which said: > In a time of heavily centralized online services, peer-to-peer is > often seen as an alternative, more democratic, and resistant > architecture that displaces structures of control over data and > communications and delegates all peers equally to be responsible for > the functioning, integrity, and security of the data. An important point about P2P is that the typical user's daily experience is not a pure P2P one but there is a big mandatory centralised step, such as ThePirateBay for BitTorrent. The use of P2P for real applications show us which features are hard to do in a fully P2P way (here, search). From nobody Mon Oct 12 06:19:04 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D231B2DDC for ; Mon, 12 Oct 2015 06:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRejJgSXH3fm for ; Mon, 12 Oct 2015 06:19:01 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312DC1B3146 for ; Mon, 12 Oct 2015 06:18:59 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3DCB428027B; Mon, 12 Oct 2015 15:18:57 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 3861B280200; Mon, 12 Oct 2015 15:18:57 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 2BF13B38039; Mon, 12 Oct 2015 15:18:27 +0200 (CEST) Date: Mon, 12 Oct 2015 15:18:27 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151012131827.GD16984@nic.fr> References: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> <561BA87C.8080708@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561BA87C.8080708@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Session confirmed - agenda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 13:19:03 -0000 On Mon, Oct 12, 2015 at 02:33:00PM +0200, Niels ten Oever wrote a message of 109 lines which said: > - - Discussion of Methodology draft (20 min) draft-varon-hrpc-methodology ? > - - Discussion of Glossary draft (10 min) draft-dkg-hrpc-glossary ? > - - Discussion of Guidelines draft (20 min) I do not see which one it is? From nobody Mon Oct 12 07:28:15 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0061B3380 for ; Mon, 12 Oct 2015 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwFrajHnN9Ei for ; Mon, 12 Oct 2015 07:28:07 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C231B3372 for ; Mon, 12 Oct 2015 07:28:00 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 27B4781C5; Mon, 12 Oct 2015 14:27:59 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 1692381D5; Mon, 12 Oct 2015 14:27:59 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 0A76581C5; Mon, 12 Oct 2015 14:27:59 +0000 (UTC) Message-ID: <561BC36E.7080600@article19.org> Date: Mon, 12 Oct 2015 16:27:58 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> <561BA87C.8080708@article19.org> <20151012131827.GD16984@nic.fr> In-Reply-To: <20151012131827.GD16984@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Session confirmed - agenda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:28:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/12/2015 03:18 PM, Stephane Bortzmeyer wrote: > On Mon, Oct 12, 2015 at 02:33:00PM +0200, Niels ten Oever > wrote a message of 109 lines which said: > >> - - Discussion of Methodology draft (20 min) > > draft-varon-hrpc-methodology ? > Yes >> - - Discussion of Glossary draft (10 min) > > draft-dkg-hrpc-glossary ? > Yes >> - - Discussion of Guidelines draft (20 min) > > I do not see which one it is? > Upcoming - we're working on it. Best, Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG8NuAAoJEAi1oPJjbWjppHwH/iMKUyJOQ1IrqVMSECnYPb/E bWsjcgySjYmba5LzVrI9fBecMsBc8MrEH2eMw7R2kdAJWDBrz5wMslGOGBEUP+xV NJd0X0rc5gDwBXl6fNUSUIqfdw96DarFbwgk9EK+HybMkTc61ykHQ7VVVFULQCqg 3+RjicxF8rv1/OT5G6iOKuXhz1Ck0S20Ci8F1Ton8yryISZTHc53MC4sY13IpkFS U7I4pmCGvoDZex8CyzvV0XvfYHJtH84oeamokbJ8YcFvnvLCR8mmPBpYcgQRAaKy WSXrDycmRnhFLEL9u8efIbteOjB3cwqLH//twe7eDdbA9C0FLtmrrx6O7nzC7XQ= =e+3V -----END PGP SIGNATURE----- From nobody Mon Oct 12 11:32:31 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F981B2AFF for ; Mon, 12 Oct 2015 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.323 X-Spam-Level: ** X-Spam-Status: No, score=2.323 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zOjk1abnEtP for ; Mon, 12 Oct 2015 11:32:28 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069671B2B00 for ; Mon, 12 Oct 2015 11:32:26 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BB0F081D8 for ; Mon, 12 Oct 2015 18:32:24 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id AB82381DB for ; Mon, 12 Oct 2015 18:32:24 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 8BD5D81D8 for ; Mon, 12 Oct 2015 18:32:24 +0000 (UTC) Message-ID: <561BFCB7.1050106@article19.org> Date: Mon, 12 Oct 2015 20:32:23 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: hrpc@irtf.org References: <5619B147.3040603@nex.sx> <20151012125313.GC16984@nic.fr> In-Reply-To: <20151012125313.GC16984@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 18:32:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/12/2015 02:53 PM, Stephane Bortzmeyer wrote: > On Sun, Oct 11, 2015 at 02:45:59AM +0200, Nex wrote > a message of 116 lines which said: > >> In a time of heavily centralized online services, peer-to-peer >> is often seen as an alternative, more democratic, and resistant >> architecture that displaces structures of control over data and >> communications and delegates all peers equally to be responsible >> for the functioning, integrity, and security of the data. > > An important point about P2P is that the typical user's daily > experience is not a pure P2P one but there is a big mandatory > centralised step, such as ThePirateBay for BitTorrent. The use of > P2P for real applications show us which features are hard to do in > a fully P2P way (here, search). > I thought this was pretty nicely solved by Tribler [0]. Best, Niels [0] https://en.wikipedia.org/wiki/Tribler -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG/y3AAoJEAi1oPJjbWjpwJAIAKhCwN991bVBs7VMQyp/VcNf /KViqyznCTgUZ7bt6B6RC0ovYLpnPDryvHBQUrO/HItgMg7vBp25uP91I6JidqZL mQD+0rgFi1XgF4tzIzMKLn3b6zkR57611QFLkMqru3mn9HqC36s+IRQQPfz6twpB LHWL8+JnaxsAvEr6WYZQGH/tfuIgktSgaDScGvZmEZ5oOCErDZHRHFe0+VsnLPLC rEvVcpdcpKO23E3tgcjYlUu22Vas3kCx4us2TLlTgqRU0I+/KCNSjB7IWRht5Fd9 s5mOQ2Tfem3A8AmiIGr5V9BosLzgOvciHdfmtNCPL6fjzJ7micSRIo03BtEC3vU= =UZDE -----END PGP SIGNATURE----- From nobody Mon Oct 12 11:43:37 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27A1B2C4B for ; Mon, 12 Oct 2015 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe4RBnX4boOM for ; Mon, 12 Oct 2015 11:43:33 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAA511B3359 for ; Mon, 12 Oct 2015 11:43:32 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t9CIhTZA001771 for ; Mon, 12 Oct 2015 14:43:29 -0400 Received: (qmail 6535 invoked by uid 0); 12 Oct 2015 18:43:29 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 12 Oct 2015 18:43:29 -0000 To: hrpc@irtf.org From: Avri Doria X-Enigmail-Draft-Status: N1110 Organization: Technicalities Message-ID: <561BFF4E.6040607@acm.org> Date: Mon, 12 Oct 2015 14:43:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 151012-0, 10/12/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] Upcoming draft on an overall report of the work X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 18:43:35 -0000 Hi, While somewhat early, wanted to proposed a document that the RG, assuming we continue to actually becoming an RG, could eventually use report of the work and first considerations once we get further down the road. This proposal, would bring together much of the work that we are doing in a single draft that we could then put forward for consideration as a RFC. At this point it is more of a glorified outline than the document I plan for it to become, but, before going too far down the road figured I should put it out as a draft, draft-doria-hrpc-report-00, before Yokohama. Which means I need to get as far as I am going to get by the 19th. In keeping with the tradition that has been set in this group of floating the markdown version of the drafts on this list before putting them out as a IDs, I enclose the following. --- title: Human Rights Protocol Considerations - Research Report docname: draft-doria-hprc-report date: 2015-10-11 category: info ipr: trust200902 area: IRTF workgroup: Human Rights Protocol Consideration RG keyword: Internet-Draft stand_alone: yes pi: rfcedstyle: yes toc: yes tocindent: yes sortrefs: yes symrefs: yes strict: yes comments: yes inline: yes text-list-symbols: -o*+ author: - ins: A. Doria name: Avri Doria org: Technicalities email: avri@acm.org normative: informative: RFC1958: RFC1984: RFC2026: RFC2639: RFC2919: RFC3365: RFC5890: RFC5891: RFC5892: RFC5893: RFC6162: RFC6783: RFC6973: RFC7230: RFC7231: RFC7232: RFC7234: RFC7235: RFC7236: RFC7237: RFC7258: UDHR: title: The Universal Declaration of Human Rights date: 1948 author: org: United Nations General Assembly target: http://www.un.org/en/documents/udhr/ HRPC-GLOSSARY: title: Human Rights Protocol Considerations Glossary date: 2015 author: - ins: N. ten Oever - ins: A. Doria - ins: D. K. Gillmor target: https://www.ietf.org/id/draft-dkg-hrpc-glossary-00.txt HRPC-Method: title: Human Rights Protocol Considerations Methodology date: 2015 author: - ins: J. Varon - ins: C. Cath target: https://www.ietf.org/id/draft-varon-hrpc-methodology-00.txt Cath: title: A case study of codeing rights date: 2015 author: - ins: C. Cath Clark: title: The Design Philosophy of the DARPA Internet Protocols author: - ins: D. Clark seriesinfo: Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114. date: 1988 Blumenthal: title: "Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world" author: - ins: M. Blumenthal - ins: D.D. Clark seriesinfo: ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109. date: 2001 Liddicoat: title: Human Rights and Internet Protocols author: - ins: J. Liddicoat - ins: A. Doria target: https://www.apc.org/en/pubs/human-rights-and-internet-protocols-comparing-proc Denardis: title: Protocol Politics author: - ins: L. Denardis date: 2013 Post: title: Internet Infrastructure and IP Censorship author: - ins: D. Post date: 2015 target: http://www.ipjustice.org/digital-rights/internet-infrastructure-and-ip-censorship-bydavid-post/ Zittrain: title: The Future of the Internet - And How to Stop It. date: 2008 author: - ins: J. Zittrain --- abstract This document present an overview of the project to map engineering concepts at the protocol level that may be related to promotion and protection of the freedom of expression and association. This first draft is intended to provide the framework for reporting on the study, initial results and basic considerations. At a later stage it will fold in the work being done in the Methodology and Glossary drafts as well as the work being done in the case studies. It also folds in some of the text included in the original proposal for the HRPC. Discussion on this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/admindb/hrpc --- middle Background ============ The recognition that human rights have a role in Internet policies has become part of the general discourse. Several reports from former United Nations (UN) Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, Frank La Rue, have made such relation explicit, which lead to the approval of the landmark resolution "on the promotion, protection and enjoyment of human rights on the Internet" at the UN Human Rights Council (HRC). And, more recently, to the resolution "The right to privacy in the digital age" at the UN General Assembly. The NETmundial outcome document affirms that human rights, as reflected in the Universal Declaration of Human Rights {{UDHR}}, should underpin Internet governance principles. Nevertheless, the direct relation between Internet Standards and human rights is still something to be explored and more clearly demonstrated. Concerns for freedom of expression and association were a strong part of the world-view of the community involved in developing the first Internet protocols. Apparently, by intention or by coincidence, the Internet was designed with freedom and openness of communications as core values. But as the scale and the commercialization of the Internet has grown, the influence of such world-views had to compete with other values, such as ease of development and cost. The purpose of this research is to discover and document the consideration involved in taking human rights into account when creating protocols. In a manner similar to the work done for RFC 6973 {{RFC6973}} on Privacy Consideration Guidelines, the premise of this research is that some standards and protocols can solidify, enable or threaten user rights. As stated in RFC 1958 {{RFC1958}}, the Internet aims to be the global network of networks that provides unfettered connectivity to all users at all times and for any content. Open, secure and reliable connectivity is essential for rights such as freedom of expression and freedom of association, as defined in the Universal Declaration of Human Rights {{UDHR}}. Therefore, considering connectivity as the ultimate objective of the Internet, this makes a clear case that the Internet is not only an enabler of human rights, but that human rights lie at the basis of, and are ingrained in, the architecture of the network. An essential part of maintaining the Internet as a tool for communication and connectivity is security. Indeed, "development of security mechanisms is seen as a key factor in the future growth of the Internet as a motor for international commerce and communication" RFC 1984 [RFC1984] and according to the Danvers Doctrine RFC 3365 {{RFC3365}}, there is an overwhelming consensus in the IETF that the best security should be used and standardized. In RFC 1984 {{RFC1984}}, the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, expressed: "concern by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy." Indeed, the IETF has been doing a significant job in this area {{RFC6973}} {{RFC7258}}, considering privacy concerns as a subset of security concerns. {{RFC6973}} Besides privacy, it should be possible to highlight other aspects of connectivity embedded in standards and protocols that can have human rights considerations. This report focuses on freedom of expression and the right to association and assembly online. Terminology ============ Currently defined in draft-dkg-hrpc-glossary to be folded in at appropriate time Link between protocols and human rights ===================================== + Include discussion of value laden engineering as discussed in {{Cath}} + Include discussion of "Values and Networks" work by Roland Bless + Include discussion of principles from NetMundial Multistakeholder Statement Discussion of Universal Declaration of Human Rights (UDHR) and Internet Architecture -------------------------------------------------------------------- This project is focused on two rights defined in the UDHR {{UDHR}}, Article 19 on Freedom of Expression and Article 20 of Freedom of Association. Article 19. : Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers. Article 20. : 1 Everyone has the right to freedom of peaceful assembly and association. : 2 No one may be compelled to belong to an association. Theory -------------- When looking at protocols the considerations can apply from several perspectives. + The protocol's direct effects on human rights on the Internet. + The protocol's direct effect on human rights in combination with other protocols + The effect of specific protocol elements, separately or in combination with other protocol elements on human rights on the Internet + The ability to determine when various effects are occurring, i.e. transparency + The effect of deployment or non deployment. While this may be may seem beyond the protocol itself, often the design of protocol, its difficulty in implementation and the degree to which it contains required elements, poison pills or other protocol artifacts that either encourage or discourse implementation or deployment can be significant in the overall human rights affect of a protocol. Other relevant research ------------------------- Look at some of the academic research on the topic including David Post, Jonathan Zittrain and Laura Denardis, among others. Methodology ============ Currently defined in detail in draft-varon-hrpc-methodolgy to be folded in at appropriate time. this will largely be a reproduction of Section 3 of that document that focuses on the methodology Briefly methodology has included: + scoping the research problem - determining terminology to be use linking engineering and human rights concepts - establishing methodology - case studies on a set of protocols - derivation of possible considerations Case Studies ============ In each of the case studies, the behavior of the protocols is analysed for its positive and negative effects. In some case these effects are due to the design of the protocol itself, in others they are due to existing or absent features. Early versions of the analysis on the following protocols are currently being discussed on HRPC list. Once the discussions have matured those discussions will be folded in this section. DNS -------------- Text being done by Will Scott on the HRPC list. IP -------------- Text being done by Will Scott on HRPC list. HTTP ------------- Text being done by Nex / Claudio on HRPC list. XMPP ------------- Text being done by Will Scott on HRPC list. P2P ------------- Text being done by Nex on HRPC List. Possible areas for protocol considerations ========================================== The case studies point to several areas of protocol behavior that may be appropriate for considerations: + Character encoding for internationalization - DNS Record - Distortion - Injection - Removal - Network Poisoning - Traffic - Interception - Manipulation - Throttling - User Identification - Source and Destination visibility - Tracking Additionally, discussion of the rights themselves and the evidence of these rights being implicits in the IETF design principles {{clark}} and in some of the existing architecture and protocols {{Cath}} {{Liddicoat}}, suggest other considerations. Next Steps ============ Once the first take at consideration are defined, what are the next steps for creating something that can be sesable for protocol designers and implementers in considering freedom of expression and and freedom of association in their work. Acknowledgement =============== A section that include the many contributors of text as as commenters and those who are assisitng this project in existing. IANA considerations =================== There shouldn't be any. Security Considerations ======================= There shouldn't be any. --- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Mon Oct 12 13:15:14 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9C1B35EC for ; Mon, 12 Oct 2015 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfupGqfaXUx9 for ; Mon, 12 Oct 2015 13:15:11 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ECF1B35EB for ; Mon, 12 Oct 2015 13:15:11 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A4337280200; Mon, 12 Oct 2015 22:15:08 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9F12C2801C2; Mon, 12 Oct 2015 22:15:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 93AA2B38025; Mon, 12 Oct 2015 22:14:38 +0200 (CEST) Date: Mon, 12 Oct 2015 22:14:38 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151012201438.GA896@nic.fr> References: <5619B147.3040603@nex.sx> <20151012125313.GC16984@nic.fr> <561BFCB7.1050106@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561BFCB7.1050106@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Cases - P2P X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 20:15:13 -0000 On Mon, Oct 12, 2015 at 08:32:23PM +0200, Niels ten Oever wrote a message of 44 lines which said: > I thought this was pretty nicely solved by Tribler [0]. I suspect there are much more ThePirateBay than Tribler users. From nobody Mon Oct 12 16:21:59 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35191A90AB for ; Mon, 12 Oct 2015 16:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZTXOs99t4wU for ; Mon, 12 Oct 2015 16:21:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5EC61A9042 for ; Mon, 12 Oct 2015 16:21:55 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1E32F22E260 for ; Mon, 12 Oct 2015 19:21:53 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 13 Oct 2015 10:21:50 +1100 To: hrpc@irtf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [hrpc] Online violence against women and girls X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 23:21:57 -0000 See: = http://www.broadbandcommission.org/publications/Pages/bb-and-gender-2015.a= spx Of particular interest might be "development of technical solutions" = under "safeguards" -- I wonder what they have in mind (full report isn't = out yet). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 12 17:12:35 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC61B2D94 for ; Mon, 12 Oct 2015 17:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abaFXzN6rkhE for ; Mon, 12 Oct 2015 17:12:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023901B2D92 for ; Mon, 12 Oct 2015 17:12:31 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B85422E260; Mon, 12 Oct 2015 20:12:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <561BA87C.8080708@article19.org> Date: Tue, 13 Oct 2015 11:12:21 +1100 Content-Transfer-Encoding: 7bit Message-Id: <8B988887-CD18-409C-A448-9023F0B579F6@mnot.net> References: <20151010012850.29540.33835.idtracker@ietfa.amsl.com> <561BA87C.8080708@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Session confirmed - agenda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 00:12:33 -0000 Hi Niels, > On 12 Oct 2015, at 11:33 pm, Niels ten Oever wrote: > > I would very much like to invite other topics and presentations to be > part of the agenda (perhaps the draft by Mark, Would love to, but unfortunately I'm chairing a BoF at the same time :-/ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 12 20:38:59 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247551B3730 for ; Mon, 12 Oct 2015 20:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F0i_iAO12XB for ; Mon, 12 Oct 2015 20:38:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA331B372F for ; Mon, 12 Oct 2015 20:38:55 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 207BE22E1F4; Mon, 12 Oct 2015 23:38:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <5615C028.4050506@cs.tcd.ie> Date: Tue, 13 Oct 2015 14:38:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9CF9A5A1-EA2A-4DC1-9BC4-7C443093706E@mnot.net> References: <20151008002412.663.7946.idtracker@ietfa.amsl.com> <5615C028.4050506@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-nottingham-for-the-users-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 03:38:58 -0000 Hi Stephen, On 8 Oct 2015, at 12:00 pm, Stephen Farrell = wrote: > - I don't know how a routing person could use this as a guide > for how to act - perhaps this is really an application layer > concept, or maybe there's a good generalisation that could be > made, I'm not sure. But considering that seems like a thing > that ought be done. (You may have done it, but that's not > visible in the draft.) I think the section on identifying / managing relevant parties should be = pretty straightforward for them; an example would help. The harder part would be showing how they prioritise the end user. I'm = wondering if the "MUST give the highest priority to end users" is = something that we need to keep -- if that section should just become an = advisory "if you don't prioritise end users, this is what's likely to = happen" rather than a MUST from above. Thoughts? > - If end-users like something that's not really good for them > (e.g. handing over all their personal information to a few > mega-companies) then are we supposed to prioritise things based > on how they behave or how we think they ought behave? (Or even > on how we think we ought behave..) Indeed. Ultimately, they need to get involved in the process to have = immediate effect, or refuse to adopt our protocols to have a more = delayed effect. Either way implies some level of organised effort (which = we do see sometimes).=20 I've done some work on the intro, see: https://github.com/mnot/I-D/commit/e76060e5bfdb > - The set of identifiable parties doesn't only include those > who benefit from our standards, but also those who lose, e.g. > hopefully criminals and spooks will lose, but so will some > companies with some business models, and so will some sets > of people. That can be important when considering trade-offs > in that the delta in outcome for a losing class of persons > may be a good, or a bad, thing. Sure. The point is to identify the actors so people can judge for = themselves whether they like the outcome, and then act accordingly (when = the document comes up for LC and when it comes time to adopt the = technology). > - If we achieve rough consensus on this text, are we then > saying that this newly BCP'd principle trumps rough consensus? That argument could be made for many documents we produce. This is a = guide; the process shows us how to apply it. > - "core values" - I'm not sure we have one set of those that we > all agree to, and perhaps we don't need that if we have a scheme > like rough consensus (see previous point) The mission statement seems to think so. > - "Extensions to existing standards MUST document..." - that's > not going to happen and, I suspect, if ever reduced to concrete > steps would end up as mere pointless bureaucracy, I think this could be stated as a goal rather than an outcome -- i.e., = it's something that the document shepherd would look into as part of the = checklist / essay ("has the impact upon the specification's relevant = parties been considered, as per BCPnnn?") > - The use of "MAY estimate" puzzles me - what does it mean? See (for this and the point above): https://github.com/mnot/I-D/commit/a54b5edeb214c3 > - "informed consent" - I think that's a fiction and a damaging > one, being impossible and yet used to justify lots of things, at > least as mostly used. ... which the text directly below acknowledges. > - I'm not sure the HTTPS as a two party protocol is a good way > to look at things. Today, a web transaction often involves a user, > operating system, browser, network operator, maybe some proxies, a > data centre/hosting/cloudy provider, a web server operator, and only > then we get to what the user may perceive as being the 2nd party. > (Which party can also be a whole menagerie of entities, an inbound > proxy or load balancer, a web front-end, ...) And all of that > omits the DNS entities, the spooks listening in and probably more. That clearly talks about it as just a protocol, not the entire Web = ecosystem. > - I'm really unsure this is something on which we could reach rough > consensus, but tha's the kind of thing I think is worth finding out. > Later though. So far, the reaction has been pretty encouraging. I think we need to = try. > - In the meantime, I hope this is on some agenda in Yokohama and for > discussion over some beers. >=20 > More nitty things: >=20 > - I don't think the code-regulates quote is useful, personally I > find it problematic, and all you need to say is that the code that > implements RFCs has obvious impact I really like it, my draft so I'll keep it for now :) > - It's somehow cute that you choose 6525 as an example of harm;-) How so? > - This really reads like something that a functioning IAB would > produce, I'm not sure what conclusion to draw from the fact that > this is being offered for discussion to a list that is not even > a formally chartered IRTF RG. Mostly, I guess that's good. But > maybe it'd be better if the IAB were emitting such drafts. (Well, > so long as the content wasn't mad of course:-) Noted. Thanks! -- Mark Nottingham https://www.mnot.net/ From nobody Tue Oct 13 13:58:40 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003A61A8BC1 for ; Tue, 13 Oct 2015 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FuWnc6Luxr5 for ; Tue, 13 Oct 2015 13:58:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57641A8BBE for ; Tue, 13 Oct 2015 13:58:36 -0700 (PDT) Received: from [192.168.0.17] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2300522E272 for ; Tue, 13 Oct 2015 16:58:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Wed, 14 Oct 2015 07:58:31 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: hrpc@irtf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [hrpc] Online violence against women and girls X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:58:39 -0000 Some more context: = http://motherboard.vice.com/read/im-disappointed-zoe-quinn-speaks-out-on-u= n-cyberviolence-report > On 13 Oct 2015, at 10:21 am, Mark Nottingham wrote: >=20 > See: > = http://www.broadbandcommission.org/publications/Pages/bb-and-gender-2015.a= spx >=20 > Of particular interest might be "development of technical solutions" = under "safeguards" -- I wonder what they have in mind (full report isn't = out yet). >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 14 00:35:55 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509701B2BD4 for ; Wed, 14 Oct 2015 00:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSUR4uKLJuJr for ; Wed, 14 Oct 2015 00:35:52 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB121B2BD0 for ; Wed, 14 Oct 2015 00:35:51 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so117949225wic.1 for ; Wed, 14 Oct 2015 00:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZcbCzF5J36zIMJZess7opT0aC0r/aIt+MprQAjdJraI=; b=C78Wivk+4iqkV24vAAe7t7USb8ZQOynm7yOjw/dfxUZENn83fm6SbfQs9+aUQCe3d8 ywklLehMIao2xknUg/ZydemRM1RncM0VN06PR9esU+yNj/kdEbSVLlh9/TDQ7pvyOlWX T3G1l7ZjknotdLZDzG89eit3nMTw8RifNy5PKWU+JoETCPlGmUTWfD5mz217QqTzVNIe i7Zqe3ysdkG9Iy0x43I6RmmSEOHQBQ4z0HTTLlSXhBVN/XKeNkUpDLcNfumoQsCamcS8 enRa0cXI1YSo5YHKU0J5lOrh00yHHl90C3uuz44jcnm2ST966wlXffTJTkYKAaHnAT43 LpSw== MIME-Version: 1.0 X-Received: by 10.180.19.68 with SMTP id c4mr26956901wie.50.1444808150416; Wed, 14 Oct 2015 00:35:50 -0700 (PDT) Received: by 10.194.30.200 with HTTP; Wed, 14 Oct 2015 00:35:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Oct 2015 08:35:50 +0100 Message-ID: From: Corinne Cath To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec53d5e2d93042305220b9cc4 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Online violence against women and girls X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 07:35:54 -0000 --bcaec53d5e2d93042305220b9cc4 Content-Type: text/plain; charset=UTF-8 on that same note: http://arstechnica.com/gaming/2015/10/un-agency-backtracks-expresses-regret-over-cyberviolence-report/ On Tue, Oct 13, 2015 at 9:58 PM, Mark Nottingham wrote: > Some more context: > > http://motherboard.vice.com/read/im-disappointed-zoe-quinn-speaks-out-on-un-cyberviolence-report > > > > On 13 Oct 2015, at 10:21 am, Mark Nottingham wrote: > > > > See: > > > http://www.broadbandcommission.org/publications/Pages/bb-and-gender-2015.aspx > > > > Of particular interest might be "development of technical solutions" > under "safeguards" -- I wonder what they have in mind (full report isn't > out yet). > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- 'The management of normality is hard work' --bcaec53d5e2d93042305220b9cc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 13, 2015 at 9:58 PM, Mark Nottingham <mnot@mn= ot.net> wrote:
Some more co= ntext:
=C2=A0 http://motherboard.vice.com/read/im-disappointed-zoe-quinn-speaks-out-on= -un-cyberviolence-report


> On 13 Oct 2015, at 10:21 am, Mark Nottingham <mnot@mnot.net> wrote:
>
> See:
>=C2=A0 http://www.b= roadbandcommission.org/publications/Pages/bb-and-gender-2015.aspx
>
> Of particular interest might be "development of technical solutio= ns" under "safeguards" -- I wonder what they have in mind (f= ull report isn't out yet).
>
> Cheers,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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



--


'The management of normality is hard work&= #39;

--bcaec53d5e2d93042305220b9cc4-- From nobody Wed Oct 14 08:33:43 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CCD1AC43A for ; Wed, 14 Oct 2015 08:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExDswTMpwU2E for ; Wed, 14 Oct 2015 08:33:38 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32F31AC43C for ; Wed, 14 Oct 2015 08:33:38 -0700 (PDT) Received: by igbhv6 with SMTP id hv6so19801653igb.0 for ; Wed, 14 Oct 2015 08:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=T+Vq9AUb6vpEmdrcw+/ZNdrzK0TsuY53bOEaWP9PWC8=; b=SxMPxJiCIsCZKHnqJ51OUW4bc/b8+BiXTijXYce/4LfDbhN8xhXakW43vTrh32iPAa 3/7zzOZvWOtdeFiKOpdflDMWkBMeu7VQRKAmD/A/5Mh7pw1sffnoNS+3/ebYIx2RKmqS fOBSpbfr7w3JnI0VQf81sy28mN8Sn9UWkp+Mk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=T+Vq9AUb6vpEmdrcw+/ZNdrzK0TsuY53bOEaWP9PWC8=; b=KPozqKDJztDtdhaU5RpWS4SgNNzA0OjGmwXHF6kcOyxiI9nRQDurQ/AouVyN68g4tB 8AZHkNHwc1T3656qzClgbELEjvmOq3+TkTJ8GDXpnx6F72Y+Hf2k82TO9la7nUk1GwpW n+dqv/CJhqRzjDZdCenPC5CSm06XPn/t0QumCI0JvcqCRkCSb4zzIHPnPzUYsz+UXBrd tTh46GvC8/aZ8Gj6oY+qIc/6soACOcTm+E/NIuczOcm75tJe/J2i5UmFvCy3XGtitcSk 9KFibvERlVlpH9Ny2JwTpQat2p9p/vpTa4Idyamp2VEOz/yJcmF9SiFD+yZPNT1Ds8oq Pu7g== X-Gm-Message-State: ALoCoQlLrgmaPfl1ViGCYVBvLKC/OnD1hzWcz2MemS2KuRETPfTc8TJ22ct0hVyDrO2qL4pgdRuv MIME-Version: 1.0 X-Received: by 10.50.64.147 with SMTP id o19mr25098889igs.52.1444836817903; Wed, 14 Oct 2015 08:33:37 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Wed, 14 Oct 2015 08:33:37 -0700 (PDT) In-Reply-To: <20151012120421.GD2465@nic.fr> References: <20151012120421.GD2465@nic.fr> Date: Wed, 14 Oct 2015 08:33:37 -0700 Message-ID: From: Will Scott Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary=047d7bea2f984a40380522124920 Archived-At: Subject: Re: [hrpc] cases - IP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:33:40 -0000 --047d7bea2f984a40380522124920 Content-Type: text/plain; charset=UTF-8 Thanks, Stephane for the feedback. I've updated this section, the patch can be seen here: https://github.com/nllz/IRTF-HRPC/compare/master...willscott:abdcc13?expand=1 --Will On Mon, Oct 12, 2015 at 5:04 AM, Stephane Bortzmeyer wrote: > On Fri, Oct 09, 2015 at 11:28:37AM -0700, > Will Scott wrote > a message of 260 lines which said: > > > The second is the selective development of IP options, so that > > protocol extensions promoting assembly and expression like Mobility > > and Multicasting can fail to receive support from IP compatible > > devices. > > Strong disagreement here. Not on the unfortunate state of IP options > (we agree here) but on the fact that IP mobility or multicasting > enable "assembly and expression". I fear you go to far in technical > determinism here. > > IP mobility, first. Technically, it is a bad idea from the beginning, > assuming layer has to handle mobility. Actually, most of the time, > mobility is better managed by applications (Pidgin for IM, all Twitter > clients for Twitter, all email clients, rsync and BitTorrent nodes for > file transfer, mosh for ssh, etc). > > Multicasting, second. Again, a bad idea from the beginning: > multicasting is only beneficial when everybody access the same content > at the very same time. Except religious ceremonies like the SuperBowl, > it is less and less common. Most interactions are not synchronous and > therefore do not depend on multicasting. > > > IPv4 even encodes a defined option and specification for source > > routing of packets, where the source can specify or suggest a > > routing path, and as the message passes through those paths, the > > part of the path it has completed are removed from the path. This > > design has the potential to make it much more difficult for an > > individual router in the network to stifle speech, > > You lost me here. Filtering based on the pair source<->destination is > most of the time done by a router which is close from the two > communicating machines. Source routing wouldn't help since you have no > choice of the edge routers. In countries where there is widespread IP > address filtering, there are only a few communcation points with the > outside and, again source routing would not help. > > A better solution, Tor, does not depend on source routing. > > > Unfortunately, many networks prevent the use of source routing, > > They are absolutely right, given the security risks of source routing. > > > The other major feature of the IP protocol header is that it > > specifies the protocol encapsulated in each message in an easily > > observable form, and does not encourage a design where the > > encapsulated protocol is not available to a network observer. > > There is an IETF-sanctioned solution, ESP. Little deployment, I > know. But any encrypting tunnel can do the same. > > > --047d7bea2f984a40380522124920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Stephane for the feedback.

I= 9;ve updated this section, the patch can be seen here:

--Will

On Mon, Oct 12, 2015 at 5:04 AM, = Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Fri, Oct 09, 2015 at 11:28:37AM -0700,
=C2=A0Will Scott <wrs@cs.washin= gton.edu> wrote
=C2=A0a message of 260 lines which said:

> The second is the selective development of IP options, so that
> protocol extensions promoting assembly and expression like Mobility > and Multicasting can fail to receive support from IP compatible
> devices.

Strong disagreement here. Not on the unfortunate state of IP options=
(we agree here) but on the fact that IP mobility or multicasting
enable "assembly and expression". I fear you go to far in technic= al
determinism here.

IP mobility, first. Technically, it is a bad idea from the beginning,
assuming layer has to handle mobility. Actually, most of the time,
mobility is better managed by applications (Pidgin for IM, all Twitter
clients for Twitter, all email clients, rsync and BitTorrent nodes for
file transfer, mosh for ssh, etc).

Multicasting, second. Again, a bad idea from the beginning:
multicasting is only beneficial when everybody access the same content
at the very same time. Except religious ceremonies like the SuperBowl,
it is less and less common. Most interactions are not synchronous and
therefore do not depend on multicasting.

> IPv4 even encodes a defined option and specification for source
> routing of packets, where the source can specify or suggest a
> routing path, and as the message passes through those paths, the
> part of the path it has completed are removed from the path. This
> design has the potential to make it much more difficult for an
> individual router in the network to stifle speech,

You lost me here. Filtering based on the pair source<->destina= tion is
most of the time done by a router which is close from the two
communicating machines. Source routing wouldn't help since you have no<= br> choice of the edge routers. In countries where there is widespread IP
address filtering, there are only a few communcation points with the
outside and, again source routing would not help.

A better solution, Tor, does not depend on source routing.

> Unfortunately, many networks prevent the use of source routing,

They are absolutely right, given the security risks of source routin= g.

> The other major feature of the IP protocol header is that it
> specifies the protocol encapsulated in each message in an easily
> observable form, and does not encourage a design where the
> encapsulated protocol is not available to a network observer.

There is an IETF-sanctioned solution, ESP. Little deployment, I
know. But any encrypting tunnel can do the same.



--047d7bea2f984a40380522124920-- From nobody Wed Oct 14 12:55:26 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308631A0364 for ; Wed, 14 Oct 2015 12:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhYu9lBoLVDE for ; Wed, 14 Oct 2015 12:55:18 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A721A0318 for ; Wed, 14 Oct 2015 12:55:17 -0700 (PDT) Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C2280172067 for ; Wed, 14 Oct 2015 21:55:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tLxp4TxIAKn8 for ; Wed, 14 Oct 2015 21:55:14 +0200 (CEST) X-Originating-IP: 95.91.242.79 Received: from [192.168.1.105] (unknown [95.91.242.79]) (Authenticated sender: lists@nex.sx) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 22658172074 for ; Wed, 14 Oct 2015 21:55:13 +0200 (CEST) To: hrpc@irtf.org From: Nex Message-ID: <561EB321.2060604@nex.sx> Date: Wed, 14 Oct 2015 21:55:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hrpc] Cases - VPN X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 19:55:24 -0000 Hello, Here are some brief considerations on the privacy and security properties of VPNs. There are more considerations to be made and a lot more technical details to get into, but I hope this could be a good start. Best, C. --- # Virtual Private Network ## Introduction A Virtual Private Network (VPN) is a point-to-point connection that enables two computers to communicate over an encrypted tunnel. There are multiple implementations and protocols used in provisioning a VPN, and they generally diversify by encryption protocol or particular requirements, most commonly in proprietary and enterprise solutions. VPNs are used commonly either to enable some devices to communicate through peculiar network configurations, or in order to use some privacy and security properties in order to protect the traffic generated by the end user; or both. VPNs have also become a very popular technology among human rights defenders, dissidents, and journalists worldwide to avoid local illegitimate wiretapping and eventually also to circumvent censorship. Among human rights defenders VPNs are often debated as a potential alternative to Tor or other anonymous networks. Such comparison is mislead, as some of the privacy and security properties of VPNs are often misunderstood by less tech-savvy users, which could ultimately lead to unintended problems. As VPNs increased in popularity, commercial VPN providers have started growing in business and are very commonly picked by human rights defenders and people at risk, as they are normally provided with an easy-to-use service and sometimes even custom applications to establish the VPN tunnel. Not being able to control the configuration of the network, and even less so the security of the application, assessing the general privacy and security state of common VPNs is very hard. Often such services have been discovered leaking information, and their custom applications have been found flawed. While Tor and similar networks receive a lot of scrutiny from the public and the academic community, commercial or non-commercial VPN networks are way less analyzed and understood, and it might be valuable to establish some standards to guarantee a minimal level of privacy and security to those who need them the most. ## False sense of Anonymity One of the common misconception among users of VPNs is the level of anonymity VPN can provide. This sense of anonymity can be betrayed by a number of attacks or misconfugrations of the VPN provider. It is important to remember that, contrarily to Tor and similar systems, VPN was not designed to provide anonymity properties. From a technical point of view, the VPN might leak identifiable information, or might be subject of correlation attacks that could expose the originating address of the connecting user. Most importantly, it is vital to understand that commercial and non-commercial VPN providers are bound by the law of the jurisdiction they reside in or in which their infrastructure is located, and they might be legally forced to turn over data of specific users if legal investigations or intelligence requirements dictate so. In such cases, if the VPN providers retain logs, it is possible that the information of the user is provided to the user's adversary and leads to his or her identification. ## Logging With VPN being point-to-point connections, the service providers are in fact able to observe the original location of the connecting users and they are able to track at what time they started their session and eventually also to which destinations they're trying to connect to. If the VPN providers retain logs for long enough, they might be forced to turn over the relevant data or they might be otherwise compromised, leading to the same data getting exposed. A clear log retaining policy could be enforced, but considering that countries enforce very different levels of data retention policies, VPN providers should at least be transparent on what information do they store and for how long is being kept. ## 3rd Party Hosting VPN providers very commonly rely on 3rd parties to provision the infrastructure that is later going to be used to run VPN endpoints. For example, they might rely on external dedicated server hosting providers, or on uplink providers. In those cases, even if the VPN provider itself isn't retaining any significant logs, the information on the connecting users might be retained by those 3rd parties instead, introducing an additional collection point for the adversary. ## IPv6 Leakage Some studies proved that several commercial VPN providers and applications suffer of critical leakage of information through IPv6 due to improper support and configuration[1]. This is generally caused by a lack of proper configuration of the client's IPv6 routing tables. Considering that most popular browsers and similar applications have been supporting IPv6 by default, if the host is provided with a functional IPv6 configuration, the traffic that is generated might be leaked if the VPN application isn't designed to manipulate such traffic properly. ## DNS Leakage Similarly, VPN services that aren't handling DNS requests and are not running DNS servers of their own, might be prone to DNS leaking which might not only expose sensitive information on the activity of the user, but could also potentially lead to DNS hijacking attacks and following compromises. ## Traffic Correlation As revelations of mass surveillance have been growing in the press, additional details on attacks on secure Internet communications have come to the public's attention. Among these, VPN appeared to be a very interesting target for attacks and collectiong efforts. Some implementations of VPN appear to be particularly vulnerable to identification and collection of key exchanges which, some Snowden documents revealed, are systematically collected and stored for future reference. The ability of an adversary to monitor network connections at many different points over the Internet, can allow them to perform traffic correlation attacks and identify the origin of certain VPN traffic by cross referencing the connection time of the user to the endpoint and the connection time of the endpoint to the final destination. These types of attacks, although very expensive and normally only performed by very resourceful adversaries, have been documented[2] to be already in practice and could completely vanify the use of a VPN and ultimately expose the activity and the identity of a user at risk. [1] http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf [2] http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html From nobody Thu Oct 15 02:35:52 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206E51A914F for ; Thu, 15 Oct 2015 02:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1yPeLvxRawc for ; Thu, 15 Oct 2015 02:35:45 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638501A914C for ; Thu, 15 Oct 2015 02:35:45 -0700 (PDT) Received: by iofl186 with SMTP id l186so83729078iof.2 for ; Thu, 15 Oct 2015 02:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=so/GRLTV4SDyfs48qUEaJLlZHBQvFACHd2xnLL16P7w=; b=HdTTvtuaOy+eNz+zcI5xv6GZ0UYLWRzCehjjtd7gvz6Hm9PLX4qYt2mE+amSu7FBkE Vn4aRtp6c0KloE8WEZa7+3vxkgfzqODd3jVR135g0hAjFm9T8D9VNwCd7UOiZL3sQtzB l7/+DUypbY0BjE1qbAsX/i390CZZ/Pyy8G3Zo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=so/GRLTV4SDyfs48qUEaJLlZHBQvFACHd2xnLL16P7w=; b=McqLPSsT3ijuXLbnTwT5E7IlgL0DkYbCnWQJE8peosaPqi0TFcHeOEekY5NaoYlIkc J2Z9HewMOA3P5GZM1NZMMBH6548rOdKo7i1lJtqKC5qfp+xxm28PDWsYHpVj2aDtZXnK 1T1UShkXLB7G2NCFcWTJG3w9UhsF0Evoa6PKmBBMk0pr1pPJkYEGxDOlCXz9WzmAazvd cpgBAHvwf5GXVFvwIWEVQQOSKD0yuWGS/iZCGDD40Xo1FV5/2iyVxYxbX7hW1FUS5xDZ UOLZUY/wUo1nxp+oo+r7xq7O/BizV4IVrtwDbFZnbJKSl5CGeiBow0e2zUJFo1UgMjCz MTmg== X-Gm-Message-State: ALoCoQlX7lLj+SgDuwCB0qh83r77ZgKcn47Z58yXTe2Mff9kuDWyaOD8brqJmoZTB+JZDOW1RKnJ MIME-Version: 1.0 X-Received: by 10.107.11.24 with SMTP id v24mr10087242ioi.184.1444901744696; Thu, 15 Oct 2015 02:35:44 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Thu, 15 Oct 2015 02:35:44 -0700 (PDT) In-Reply-To: <561BA3B7.8030907@article19.org> References: <5614667C.5090508@article19.org> <20151007100153.GB20416@nic.fr> <5614F9B5.6020304@article19.org> <20151007111244.GA29746@nic.fr> <5619181C.5090404@acm.org> <561BA3B7.8030907@article19.org> Date: Thu, 15 Oct 2015 02:35:44 -0700 Message-ID: From: Will Scott To: Niels ten Oever Content-Type: multipart/alternative; boundary=001a113f90703a7900052221676e Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases -> DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:35:51 -0000 --001a113f90703a7900052221676e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the great set of comments. I've tried to incorporate them into a second draft: https://github.com/willscott/IRTF-HRPC/commit/808c9b57bbf50e6ba3c717e73445a= 8ef8f97991b As before, feedback is welcome. One point I haven't included that might be worth including is a discussion of name minimization. In the initial DNS implementation, and continuing in many resolvers, the requests to the root server and tld server include the full requested name. This has resulted in passive surveillance of those high-traffic servers. On Mon, Oct 12, 2015 at 5:12 AM, Niels ten Oever wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Will, > > Since it is the most prevalent attack, I do not think it should be > dropped, but it should be shown this is mitigated by the use of > DNSSEC. However DNSSEC is not mandatory, so the the protocol still > allows for this vulnerability imho. > > Best, > > Niels > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 10/10/2015 06:53 PM, Will Scott wrote: > > Thanks for all the feedback. I'm working through updating the the > > first draft, and will drop root server discussion and will do some > > more diligence at living in our modern dnssec world. > > > > Injection of records, as in the case of China, does seem to be one > > of the major attacks that the protocol has historically (and in > > practice continues) to be vulnerable to; despite being mitigated by > > DNSSEC. I'd be interested in input in how that might be most > > effectively framed. Andrew seems to suggest the injection section > > is hard to justify from the protocol, and hurts the argument. Is > > there consensus that it should be dropped? > > > > --Will > > > > > > On Sat, Oct 10, 2015 at 6:52 AM, Avri Doria > > wrote: > > > > > > > > On 07-Oct-15 07:12, Stephane Bortzmeyer wrote: > >> As I said, it is one of the best kept secrets of Internet > >> governance. The professionals of the governance circus typically > >> ignore this issue (too practical? too difficult?). > > > > I am not sure it is either a secret of has always been ignored. I > > remember it being discussed as far back as the working Group on > > Internet Goverance (WGIG) in 2005. The WGIG Report says the > > following: > >> Lack of formal relationship with root server operators. =E2=80=A2 The > >> root zone operators perform their functions today without a > >> formal relationship with any authority. > > > > The WGIG Background report also contains a discussion, though not > > as explicit as yours. There have been other references over the > > years in various Internet Governance Forum (IGF) and other > > discussions. > > > > Over the years there have been many discussions in the various > > Internet governance venues of the fact that root server operators > > are each independent operators, who do what they do based on their > > own decisions with loose informal coordination among themselves. > > This notion of informal coordination is central to much of the > > technical management of the Internet. There are those who have > > wanted to find a way to add international governance to that, but > > up to now that has remained a non starter. As you say, it may be > > too difficult. > > > > There have also been some discussions over the years questioning > > whether DNSSEC in some sense bound these root server a bit more as > > it removed some of their discretion about which records they > > accepted, providing a technical measure of coordination. > > > > I am not making a normative statement at this point about whether > > this independence and the DNSSEC are helpful or not to freedom of > > expression and association, but just trying to argue that is not > > quite as deep and dark a secret among the 'circus' professionals > > as presented. I do agree that getting Internet governance of the > > root server operators does not seem to be a current work item - > > root servers are not even mentioned in the early drafts of WSIS+10 > > paper the UN General Assembly will be approving at the end of the > > year. I am also sure that many of the participants in Internet > > governance know nothing about this, but it isn't a dark secret and > > it has been discussed over the years. > > > > avri > > > > > > > > > > > > > > > > --- This email has been checked for viruses by Avast antivirus > > software. https://www.avast.com/antivirus > > > > _______________________________________________ hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > > > > > > > _______________________________________________ hrpc mailing list > > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWG6O3AAoJEAi1oPJjbWjpiXIH/0vonZjISozLnUa9Q5cocpo6 > EGzmv2AWWsjhe34URPgh5DRvs9Yp9XI1DDbHbLihGUtfBhLsYXLOSU5Y5z0pAoDc > JnQffhaWLUZgTIJPGQcqGbeKCTsudhsPcWnnu94XV2iSpysAOJyEphgnjrxWejoV > qHkyLwgSb+Vcx54R25e0gc8IJ0g4PvHf/tIHkx/3oxrG7LpQ+M4VOwz/FA/E72De > zpu4eEMQ4BRXbb7GkniR9qPip1eCCvb/HY9LD8SIZvXglRePTlEda9Ww3+92S60S > 75lDfKrIw63weu3w5E+wDZgMVScOZ857yY+hCXNZ9l+2Sx/5cKslIY49I+WXMN0=3D > =3DUUS6 > -----END PGP SIGNATURE----- > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --001a113f90703a7900052221676e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the great set of comments.=C2=A0 I've tried= to incorporate them into a second draft:


As before, feedback is w= elcome.
One point I haven't included that might be worth incl= uding is a discussion of name minimization. In the initial DNS implementati= on, and continuing in many resolvers, the requests to the root server and t= ld server include the full requested name.=C2=A0 This has resulted in passi= ve surveillance of those high-traffic servers.

On Mon, Oct 12, 2015 at 5:12 AM, N= iels ten Oever <niels@article19.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Will,

Since it is the most prevalent attack, I do not think it should be
dropped, but it should be shown this is mitigated by the use of
DNSSEC. However DNSSEC is not mandatory, so the the protocol still
allows for this vulnerability imho.

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
w= ww.article19.org

PGP fingerprint=C2=A0 =C2=A0 8D9F C567 BEE4 A431 56C4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0678B 0= 8B5 A0F2 636D 68E9

On 10/10/2015 06:53 PM, Will Scott wrote:
> Thanks for all the feedback. I'm working through updating the the<= br> > first draft, and will drop root server discussion and will do some
> more diligence at living in our modern dnssec world.
>
> Injection of records, as in the case of China, does seem to be one
> of the major attacks that the protocol has historically (and in
> practice continues) to be vulnerable to; despite being mitigated by > DNSSEC.=C2=A0 I'd be interested in input in how that might be most=
> effectively framed. Andrew seems to suggest the injection section
> is hard to justify from the protocol, and hurts the argument. Is
> there consensus that it should be dropped?
>
> --Will
>
>
> On Sat, Oct 10, 2015 at 6:52 AM, Avri Doria <avri@acm.org
> <mailto:avri@acm.org>> wrote:
>
>
>
> On 07-Oct-15 07:12, Stephane Bortzmeyer wrote:
>> As I said, it is one of the best kept secrets of Internet
>> governance. The professionals of the governance circus typically >> ignore this issue (too practical? too difficult?).
>
> I am not sure it is either a secret of has always been ignored.=C2=A0 = I
> remember it being discussed as far back as the working Group on
> Internet Goverance (WGIG) in 2005. The WGIG Report says the
> following:
>> Lack of formal relationship with root server operators. =E2=80=A2 = The
>> root zone operators perform their functions today without a
>> formal relationship with any authority.
>
> The WGIG Background report also contains a discussion, though not
> as explicit as yours. There have been other references over the
> years in various Internet Governance Forum (IGF) and other
> discussions.
>
> Over the years there have been many discussions in the various
> Internet governance venues of the fact that root server operators
> are each independent operators,=C2=A0 who do what they do based on the= ir
> own decisions with loose informal coordination among themselves.
> This notion of informal coordination is central to much of the
> technical management of the Internet.=C2=A0 There are those who have > wanted to find a way to add international governance to that, but
> up to now that has remained a non starter. As you say, it may be
> too difficult.
>
> There have also been some discussions over the years questioning
> whether DNSSEC in some sense bound these root server a bit more as
> it removed some of their=C2=A0 discretion about which records they
> accepted, providing a technical measure of coordination.
>
> I am not making a normative statement at this point about whether
> this independence and the DNSSEC are helpful or not to freedom of
> expression and association, but just trying to argue that is not
> quite as=C2=A0 deep and dark a secret among the 'circus' profe= ssionals
> as presented.=C2=A0 I do agree that getting Internet governance of the=
> root server operators does not seem to be a current work item -
> root servers are not even mentioned in the early drafts of=C2=A0 WSIS+= 10
> paper the UN General Assembly will be approving at the end of the
> year.=C2=A0 I am also sure that many of the participants in Internet > governance know nothing about this, but it isn't a dark secret and=
> it has been discussed over the years.
>
> avri
>
>
>
>
>
>
>
> --- This email has been checked for viruses by Avast antivirus
> software. https://www.avast.com/antivirus
>
> _______________________________________________ hrpc mailing list
> hrpc@irtf.org <mai= lto:hrpc@irtf.org>
> https://www.irtf.org/mailman/listinfo/hrpc
>
>
>
>
> _______________________________________________ hrpc mailing list
> hrpc@irtf.org ht= tps://www.irtf.org/mailman/listinfo/hrpc
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWG6O3AAoJEAi1oPJjbWjpiXIH/0vonZjISozLnUa9Q5cocpo6
EGzmv2AWWsjhe34URPgh5DRvs9Yp9XI1DDbHbLihGUtfBhLsYXLOSU5Y5z0pAoDc
JnQffhaWLUZgTIJPGQcqGbeKCTsudhsPcWnnu94XV2iSpysAOJyEphgnjrxWejoV
qHkyLwgSb+Vcx54R25e0gc8IJ0g4PvHf/tIHkx/3oxrG7LpQ+M4VOwz/FA/E72De
zpu4eEMQ4BRXbb7GkniR9qPip1eCCvb/HY9LD8SIZvXglRePTlEda9Ww3+92S60S
75lDfKrIw63weu3w5E+wDZgMVScOZ857yY+hCXNZ9l+2Sx/5cKslIY49I+WXMN0=3D
=3DUUS6
-----END PGP SIGNATURE-----

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

--001a113f90703a7900052221676e-- From nobody Thu Oct 15 08:34:31 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8E1B337E for ; Thu, 15 Oct 2015 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_3IVos4qBBN for ; Thu, 15 Oct 2015 08:34:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A06C1B3379 for ; Thu, 15 Oct 2015 08:34:24 -0700 (PDT) Received: by qkap81 with SMTP id p81so40519267qka.2 for ; Thu, 15 Oct 2015 08:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rgrIIy8L0BSiTYuQ3+WG/Qxsl0Urh9pDMzZb8nl1snY=; b=brRWkN12ksja3Eq9c5D4OKX/TqlI+M7ec49eEhorFnHPd1lBJVYjPTkbdUuUxe5pWz 8Ou+r6cyf8fC9MHodaWT9T+0GWetPZK42VwlnYo0a8dAULYYgjpJbnsxWf9fwdSYWflu pKrIZVwk/jmh/KMQhYfcO9NZM97T+xbY63hrGeN4jZe7PF8CIw/MBerBXXWtMY1R2h/K pUmhaRSs7CK9YO+Wa5OZa4X7VZCt9k9sZzO37r7U4p2ouBsUzGSn+r0bm/6el84GEnoI /Jd+5AbTbUblrvN5ymAw+eWDhJ9elGTKgyXzGYQ05urEHEyv33TOyFtyjfbT3aQOoj3o 9WZQ== MIME-Version: 1.0 X-Received: by 10.195.17.163 with SMTP id gf3mr11308797wjd.105.1444923263356; Thu, 15 Oct 2015 08:34:23 -0700 (PDT) Received: by 10.194.30.200 with HTTP; Thu, 15 Oct 2015 08:34:23 -0700 (PDT) In-Reply-To: <561BFF4E.6040607@acm.org> References: <561BFF4E.6040607@acm.org> Date: Thu, 15 Oct 2015 16:34:23 +0100 Message-ID: From: Corinne Cath To: Avri Doria Content-Type: multipart/alternative; boundary=089e01681c56d7190e0522266951 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Upcoming draft on an overall report of the work X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:34:30 -0000 --089e01681c56d7190e0522266951 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great! had some minor suggestions (see in-text), feel free to ignore. Best from a cold and rainy Paris. On Mon, Oct 12, 2015 at 7:43 PM, Avri Doria wrote: > Hi, > > While somewhat early, wanted to proposed a document that the RG, > assuming we continue to actually becoming an RG, could eventually use > report of the work and first considerations once we get further down the > road. > > This proposal, would bring together much of the work that we are doing > in a single draft that we could then put forward for consideration as a > RFC. > > At this point it is more of a glorified outline than the document I plan > for it to become, but, before going too far down the road figured I > should put it out as a draft, draft-doria-hrpc-report-00, before > Yokohama. Which means I need to get as far as I am going to get by the > 19th. > > In keeping with the tradition that has been set in this group of > floating the markdown version of the drafts on this list before putting > them out as a IDs, I enclose the following. > > --- > title: Human Rights Protocol Considerations - Research Report > docname: draft-doria-hprc-report > date: 2015-10-11 > category: info > > ipr: trust200902 > > area: IRTF > workgroup: Human Rights Protocol Consideration RG > keyword: Internet-Draft > stand_alone: yes > pi: > rfcedstyle: yes > toc: yes > tocindent: yes > sortrefs: yes > symrefs: yes > strict: yes > comments: yes > inline: yes > text-list-symbols: -o*+ > > author: > - > ins: A. Doria > name: Avri Doria > org: Technicalities > email: avri@acm.org > > normative: > > informative: > RFC1958: > RFC1984: > RFC2026: > RFC2639: > RFC2919: > RFC3365: > RFC5890: > RFC5891: > RFC5892: > RFC5893: > RFC6162: > RFC6783: > RFC6973: > RFC7230: > RFC7231: > RFC7232: > RFC7234: > RFC7235: > RFC7236: > RFC7237: > RFC7258: > UDHR: > title: The Universal Declaration of Human Rights > date: 1948 > author: > org: United Nations General Assembly > target: http://www.un.org/en/documents/udhr/ > > HRPC-GLOSSARY: > title: Human Rights Protocol Considerations Glossary > date: 2015 > author: > - ins: N. ten Oever > - ins: A. Doria > - ins: D. K. Gillmor > target: https://www.ietf.org/id/draft-dkg-hrpc-glossary-00.txt > > HRPC-Method: > title: Human Rights Protocol Considerations Methodology > date: 2015 > author: > - ins: J. Varon > - ins: C. Cath > target: https://www.ietf.org/id/draft-varon-hrpc-methodology-00.txt > > Cath: > title: A case study of codeing rights > date: 2015 > author: > - ins: C. Cath > > Clark: > title: The Design Philosophy of the DARPA Internet Protocols > author: > - ins: D. Clark > seriesinfo: Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August > 1988, pp. 106-114. > date: 1988 > > Blumenthal: > title: "Rethinking the design of the Internet: The end-to-end > arguments vs. the brave new world" > author: > - ins: M. Blumenthal > - ins: D.D. Clark > seriesinfo: ACM Transactions on Internet Technology, Vol. 1, No. 1, > August 2001, pp 70-109. > date: 2001 > > > Liddicoat: > title: Human Rights and Internet Protocols > author: > - ins: J. Liddicoat > - ins: A. Doria > target: > > https://www.apc.org/en/pubs/human-rights-and-internet-protocols-comparing= -proc > > Denardis: > title: Protocol Politics > author: > - ins: L. Denardis > date: 2013 > > Post: > title: Internet Infrastructure and IP Censorship > author: > - ins: D. Post > date: 2015 > target: > > http://www.ipjustice.org/digital-rights/internet-infrastructure-and-ip-ce= nsorship-bydavid-post/ > > Zittrain: > title: The Future of the Internet - And How to Stop It. > date: 2008 > author: > - ins: J. Zittrain > > --- abstract > > This document present an overview of the project to map engineering > concepts at the protocol level that may be related to promotion and > protection of the freedom of expression and association. > > This first draft is intended to provide the framework for reporting on > the study, initial results and basic considerations. At a later stage it > will fold in the work being done in the Methodology and Glossary drafts > as well as the work being done in the case studies. It also folds in > some of the text included in the original proposal for the HRPC. > > Discussion on this draft at: hrpc@irtf.org // > https://www.irtf.org/mailman/admindb/hrpc > > > --- middle > > > Background > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The recognition that human rights have a role in Internet policies has > become part of the general discourse. Several reports from former > United Nations (UN) Special Rapporteur on the promotion and protection > of the right to freedom of opinion and expression, Frank La Rue, have > made such relation explicit, which lead to the approval of the landmark > resolution "on the promotion, protection and enjoyment of human rights > on the Internet" at the UN Human Rights Council (HRC). And, more > recently, to the resolution "The right to privacy in the digital age" at > the UN General Assembly. The NETmundial outcome document affirms that > human rights, as reflected in the Universal Declaration of Human Rights > {{UDHR}}, should underpin Internet governance principles. > > =E2=80=8BPerhaps it is also interesting to mention the recent UNESCO study? http://www.unesco.org/new/en/internetstudy as it focuses specifically on the importance of developing the Internet on the basis of human rights principles. =E2=80=8B > Nevertheless, the direct relation between Internet Standards and human > rights is still something to be explored and more clearly demonstrated. > > Concerns for freedom of expression and association were > =E2=80=8B > =E2=80=8Bare?=E2=80=8B > =E2=80=8B > a strong part of > the world-view of the community involved in developing the first > Internet protocols. Apparently, by intention or by coincidence, the > Internet was designed with freedom and openness of communications as > core values. But as the scale and the commercialization of the > Internet has grown, the influence of such world-views had to compete > with other values, such as ease of development and cost. The purpose of > this research is to discover and document the consideration involved in > taking human rights into account when creating protocols. > > In a manner similar to the work done for RFC 6973 {{RFC6973}} on Privacy > Consideration Guidelines, the premise of this research is that some > standards and protocols can solidify, enable or threaten user rights. > =E2=80=8BI think we need to be careful about using "user rights" and "human= rights" interchangeably - it's confusing, and user rights have a completely different legal basis than human rights (sorry for being Cpt. Obvious here). But it's feedback I have gotten on a continous basis, and is a legitimate issue to address I feel.=E2=80=8B > > As stated in RFC 1958 {{RFC1958}}, the Internet aims to be the global > network of networks that provides unfettered connectivity to all users > at all times and for any content. Open, secure and reliable > connectivity is essential for rights such as freedom of expression and > freedom of association, as defined in the Universal Declaration of > Human Rights {{UDHR}}. Therefore, considering connectivity as the > ultimate objective of the Internet, this makes a clear case that the > Internet is not only an enabler of human rights, but that human rights > lie at the basis of, and are ingrained in, the architecture of the > network. > =E2=80=8Bwoot woot!=E2=80=8B > > An essential part of maintaining the Internet as a tool for > communication and connectivity is security. Indeed, "development of > security mechanisms is seen as a key factor in the future growth of the > Internet as a motor for international commerce and communication" RFC > 1984 [RFC1984] and according to the Danvers Doctrine RFC 3365 > {{RFC3365}}, there is an overwhelming consensus in the IETF that the > best security should be used and standardized. > > In RFC 1984 {{RFC1984}}, the Internet Architecture Board (IAB) and the > Internet Engineering Steering Group (IESG), the bodies which oversee > architecture and standards for the Internet, expressed: "concern by the > need for increased protection of international commercial transactions > on the Internet, and by the need to offer all Internet users an > adequate degree of privacy." Indeed, the IETF has been doing a > significant job in this area {{RFC6973}} {{RFC7258}}, considering > privacy concerns as a subset of security concerns. {{RFC6973}} > > Besides privacy, it should be possible to highlight other aspects of > connectivity embedded in standards and protocols that can have human > rights considerations. This report focuses on freedom of expression and > the right to association and assembly online. > > Terminology > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Currently defined in draft-dkg-hrpc-glossary to be folded in at > appropriate time > > Link between protocols and human rights > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + Include discussion of value laden engineering as discussed in {{Cath}} > + Include discussion of "Values and Networks" work by Roland Bless > + Include discussion of principles from NetMundial Multistakeholder > Statement > > > Discussion of Universal Declaration of Human Rights (UDHR) and Internet > Architecture > -------------------------------------------------------------------- > > This project is focused on two rights defined in the UDHR {{UDHR}}, > Article 19 on Freedom of Expression and Article 20 of Freedom of > Association. > > Article 19. > : Everyone has the right to freedom of opinion and expression; this > right includes freedom to hold opinions without interference and to > seek, receive and impart information and ideas through any media and > regardless of frontiers. > > Article 20. > : 1 Everyone has the right to freedom of peaceful assembly and > association. > : 2 No one may be compelled to belong to an association. > > > Theory > -------------- > > When looking at protocols the considerations can apply from several > perspectives. > > + The protocol's direct effects on human rights on the Internet. > + The protocol's direct effect on human rights in combination with > other protocols > + The effect of specific protocol elements, separately or in > combination with other protocol elements on human rights on the Internet > + The ability to determine when various effects are occurring, i.e. > transparency > + The effect of deployment or non deployment. While this may be may > seem beyond the protocol itself, often the design of protocol, its > difficulty in implementation and the degree to which it contains > required elements, poison pills or other protocol artifacts that either > encourage or discourse implementation or deployment can be significant > in the overall human rights affect of a protocol. > > > Other relevant research > ------------------------- > > Look at some of the academic research on the topic including David Post, > Jonathan Zittrain and Laura Denardis, among others. > > =E2=80=8BPerhaps also add Alexander Galloway's "Protocol"? and some of th= e work of Ian Brown?=E2=80=8B > Methodology > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Currently defined in detail in draft-varon-hrpc-methodolgy to be folded > in at appropriate time. this will largely be a reproduction of Section > 3 of that document that focuses on the methodology > > Briefly methodology has included: > + scoping the research problem > - determining terminology to be use linking engineering and human rights > concepts > - establishing methodology > - case studies on a set of protocols > - derivation of possible considerations > > Case Studies > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In each of the case studies, the behavior of the protocols is analysed > for its positive and negative effects. In some case these effects are > due to the design of the protocol itself, in others they are due to > existing or absent features. > > Early versions of the analysis on the following protocols are currently > being discussed on HRPC list. Once the discussions have matured those > discussions will be folded in this section. > > DNS > -------------- > > Text being done by Will Scott on the HRPC list. > > IP > -------------- > > Text being done by Will Scott on HRPC list. > > HTTP > ------------- > > Text being done by Nex / Claudio on HRPC list. > > XMPP > ------------- > > Text being done by Will Scott on HRPC list. > > P2P > ------------- > > Text being done by Nex on HRPC List. > > > Possible areas for protocol considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The case studies point to several areas of protocol behavior that may be > appropriate for considerations: > > + Character encoding for internationalization > - DNS Record > - Distortion > - Injection > - Removal > - Network Poisoning > - Traffic > - Interception > - Manipulation > - Throttling > - User Identification > - Source and Destination visibility > - Tracking > > Additionally, discussion of the rights themselves and the evidence of > these rights being implicits in the IETF design principles {{clark}} and > in some of the existing architecture and protocols {{Cath}} > {{Liddicoat}}, suggest other considerations. > > Next Steps > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Once the first take at consideration are defined, what are the next > steps for creating something that can be sesable for protocol designers > and implementers in considering freedom of expression and and freedom of > association in their work. > > Acknowledgement > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A section that include the many contributors of text as as commenters > and those who are assisitng this project in existing. > > IANA considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > There shouldn't be any. > > Security Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > There shouldn't be any. > > --- > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --=20 'The management of normality is hard work' --089e01681c56d7190e0522266951 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great! had some minor suggestions (see in-text), feel free to ignore= . Best from a cold and rainy Paris.
On Mon, Oct 12, 2015 at 7:43 PM, Avri Doria <avri@a= cm.org> wrote:
Hi,

While somewhat early, wanted to proposed a document that the RG,
assuming we continue to actually becoming an RG, could eventually use
report of the work and first considerations once we get further down the road.

This proposal, would bring together much of the work that we are doing
in a single draft that we could then put forward for consideration as a RFC= .

At this point it is more of a glorified outline than the document I plan for it to become, but, before going too far down the road figured I
should put it out as a draft, draft-doria-hrpc-report-00,=C2=A0 before
Yokohama.=C2=A0 Which means I need to get as far as I am going to get by th= e
19th.

In keeping with the tradition that has been set in this group of
floating the markdown version of the drafts on this list before putting
them out as a IDs, I enclose the following.

---
title: Human Rights Protocol Considerations - Research Report
docname: draft-doria-hprc-report
date: 2015-10-11
category: info

ipr: trust200902

area: IRTF
workgroup: Human Rights Protocol Consideration RG
keyword: Internet-Draft
stand_alone: yes
pi:
=C2=A0 rfcedstyle: yes
=C2=A0 toc: yes
=C2=A0 tocindent: yes
=C2=A0 sortrefs: yes
=C2=A0 symrefs: yes
=C2=A0 strict: yes
=C2=A0 comments: yes
=C2=A0 inline: yes
=C2=A0 text-list-symbols: -o*+

author:
-
=C2=A0 ins: A. Doria
=C2=A0 name: Avri Doria
=C2=A0 org: Technicalities
=C2=A0 email: avri@acm.org

normative:

informative:
=C2=A0 RFC1958:
=C2=A0 RFC1984:
=C2=A0 RFC2026:
=C2=A0 RFC2639:
=C2=A0 RFC2919:
=C2=A0 RFC3365:
=C2=A0 RFC5890:
=C2=A0 RFC5891:
=C2=A0 RFC5892:
=C2=A0 RFC5893:
=C2=A0 RFC6162:
=C2=A0 RFC6783:
=C2=A0 RFC6973:
=C2=A0 RFC7230:
=C2=A0 RFC7231:
=C2=A0 RFC7232:
=C2=A0 RFC7234:
=C2=A0 RFC7235:
=C2=A0 RFC7236:
=C2=A0 RFC7237:
=C2=A0 RFC7258:
=C2=A0 UDHR:
=C2=A0 =C2=A0 title: The Universal Declaration of Human Rights
=C2=A0 =C2=A0 date: 1948
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 org: United Nations General Assembly
=C2=A0 =C2=A0 target: http://www.un.org/en/documents/udhr/<= br>
=C2=A0 HRPC-GLOSSARY:
=C2=A0 =C2=A0 title: Human Rights Protocol Considerations Glossary
=C2=A0 =C2=A0 date: 2015
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: N. ten Oever
=C2=A0 =C2=A0 =C2=A0 - ins: A. Doria
=C2=A0 =C2=A0 =C2=A0 - ins: D. K. Gillmor
=C2=A0 =C2=A0 target: https://www.ietf.org/id/= draft-dkg-hrpc-glossary-00.txt

=C2=A0 HRPC-Method:
=C2=A0 =C2=A0 title: Human Rights Protocol Considerations Methodology
=C2=A0 =C2=A0 date: 2015
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: J. Varon
=C2=A0 =C2=A0 =C2=A0 - ins: C. Cath
=C2=A0 =C2=A0 target: https://www.ietf.or= g/id/draft-varon-hrpc-methodology-00.txt

=C2=A0 Cath:
=C2=A0 =C2=A0 title: A case study of codeing rights
=C2=A0 =C2=A0 date: 2015
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- ins: C. Cath

=C2=A0 Clark:
=C2=A0 =C2=A0 title: The Design Philosophy of the DARPA Internet Protocols<= br> =C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: D. Clark
=C2=A0 =C2=A0 seriesinfo: Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1988, pp. 106-114.
=C2=A0 =C2=A0 date: 1988

=C2=A0 Blumenthal:
=C2=A0 =C2=A0 title: "Rethinking the design of the Internet: The end-t= o-end
arguments vs. the brave new world"
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- ins: M. Blumenthal
=C2=A0 =C2=A0 =C2=A0 =C2=A0- ins: D.D. Clark
=C2=A0 =C2=A0 seriesinfo: ACM Transactions on Internet Technology, Vol. 1, = No. 1,
August 2001, pp 70-109.
=C2=A0 =C2=A0 date: 2001


=C2=A0 Liddicoat:
=C2=A0 =C2=A0 title: Human Rights and Internet Protocols
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- ins: J. Liddicoat
=C2=A0 =C2=A0 =C2=A0 =C2=A0- ins: A. Doria
=C2=A0 =C2=A0 target:
https://www.apc.org/en= /pubs/human-rights-and-internet-protocols-comparing-proc

=C2=A0 Denardis:
=C2=A0 =C2=A0 title: Protocol Politics
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: L. Denardis
=C2=A0 =C2=A0 date: 2013

=C2=A0 Post:
=C2=A0 =C2=A0 title: Internet Infrastructure and IP Censorship
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: D. Post
=C2=A0 =C2=A0 date: 2015
=C2=A0 =C2=A0 target:
http:= //www.ipjustice.org/digital-rights/internet-infrastructure-and-ip-censorshi= p-bydavid-post/

=C2=A0 Zittrain:
=C2=A0 =C2=A0 title: The Future of the Internet - And How to Stop It.
=C2=A0 =C2=A0 date: 2008
=C2=A0 =C2=A0 author:
=C2=A0 =C2=A0 =C2=A0 - ins: J. Zittrain

--- abstract

This document present an overview of the project to map engineering
concepts at the protocol level that may be related to promotion and
protection of the freedom of expression and association.

This first draft is intended to provide the framework for reporting on
the study, initial results and basic considerations. At a later stage it will fold in the work being done in the Methodology and Glossary drafts
as well as the work being done in the case studies. It also folds in
some of the text included in the original proposal for the HRPC.

Discussion on this draft at: hrpc@irtf.org= //
https://www.irtf.org/mailman/admindb/hrpc


--- middle


Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The recognition that human rights have a role in Internet policies has
become part of the general discourse.=C2=A0 Several reports from former
United Nations (UN) Special Rapporteur on the promotion and protection
of the right to freedom of opinion and expression, Frank La Rue, have
made such relation explicit, which lead to the approval of the landmark
resolution "on the promotion, protection and enjoyment of human rights=
on the Internet" at the UN Human Rights Council (HRC).=C2=A0 And, more=
recently, to the resolution "The right to privacy in the digital age&q= uot; at
the UN General Assembly.=C2=A0 The NETmundial outcome document affirms that=
human rights, as reflected in the Universal Declaration of Human Rights
{{UDHR}}, should underpin Internet governance principles.


=E2=80=8BPerhaps it is also interesting to m= ention the recent UNESCO study?
http://www.unesco.org/new/en/internetstudy
as it focuses specifically on the importance of developing the Internet on= the basis of human rights principles.

=E2=80=8B
=C2=A0
Nevertheless, the direct relation between Internet Standards and human
rights is still something to be explored and more clearly demonstrated.

Concerns for freedom of expression and association were
=E2=80=8B
=E2=80=8Bare?=E2=80=8B
=C2=A0
=E2=80=8B
a strong part= of
the world-view of the community involved in developing the first
Internet protocols.=C2=A0 Apparently, by intention or by coincidence, the Internet was designed with freedom and openness of communications as
core values.=C2=A0 But as the scale and the commercialization of the
Internet has grown, the influence of such world-views had to compete
with other values, such as ease of development and cost. The purpose of
this research is to discover and document the consideration involved in
taking human rights into account when creating protocols.

In a manner similar to the work done for RFC 6973 {{RFC6973}} on Privacy Consideration Guidelines, the premise of this research is that some
standards and protocols can solidify, enable or threaten user rights.

=E2=80=8BI think we need to be careful about using= "user rights" and "human rights" interchangeably - it&= #39;s confusing, and
user rights have a completely different = legal basis than human rights (sorry for being Cpt. Obvious here). But
<= /div>
it's feedback I have gotten on a continous basis, and is a le= gitimate issue to address I feel.=E2=80=8B
=C2=A0

As stated in RFC 1958 {{RFC1958}}, the Internet aims to be the global
network of networks that provides unfettered connectivity to all users
at all times and for any content.=C2=A0 Open, secure and reliable
connectivity is essential for rights such as freedom of expression and
freedom of association, as defined in the Universal Declaration=C2=A0 =C2= =A0of
Human Rights {{UDHR}}.=C2=A0 Therefore, considering connectivity as the
ultimate objective of the Internet, this makes a clear case that the
Internet is not only an enabler of human rights, but that human rights
lie at the basis of, and are ingrained in, the architecture of=C2=A0 =C2=A0= the
network.

=E2=80=8Bwoot woot!=E2=80=8B
= =C2=A0

An essential part of maintaining the Internet as a tool for
communication and connectivity is security.=C2=A0 Indeed, "development= of
security mechanisms is seen as a key factor in the future growth of=C2=A0 t= he
Internet as a motor for international commerce and communication"=C2= =A0 =C2=A0RFC
1984 [RFC1984] and according to the Danvers Doctrine RFC 3365
{{RFC3365}}, there is an overwhelming consensus in the IETF that the
best security should be used and standardized.

In RFC 1984 {{RFC1984}}, the Internet Architecture Board (IAB) and the
Internet Engineering Steering Group (IESG), the bodies which oversee
architecture and standards for the Internet, expressed: "concern by=C2= =A0 the
need for increased protection of international commercial=C2=A0 =C2=A0trans= actions
on the Internet, and by the need to offer all Internet=C2=A0 =C2=A0users an=
adequate degree of privacy."=C2=A0 Indeed, the IETF has been=C2=A0 =C2= =A0doing a
significant job in this area {{RFC6973}} {{RFC7258}}, considering
privacy concerns as a subset of security concerns.=C2=A0 {{RFC6973}}

Besides privacy, it should be possible to highlight other aspects of
connectivity embedded in standards and protocols that can have human
rights considerations. This report focuses on freedom of expression and
the right to association and assembly online.

Terminology
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Currently defined in draft-dkg-hrpc-glossary to be folded in at
appropriate time

Link between protocols and human rights
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

+ Include discussion of value laden engineering as discussed in {{Cath}} + Include discussion of=C2=A0 "Values and Networks" work by Rolan= d Bless
+ Include discussion of principles from NetMundial Multistakeholder
Statement


Discussion of Universal Declaration of Human Rights (UDHR) and Internet
Architecture
--------------------------------------------------------------------

This project is focused on two rights defined in the UDHR {{UDHR}},
Article 19 on Freedom of Expression and Article 20 of Freedom of
Association.

Article 19.
:=C2=A0 =C2=A0Everyone has the right to freedom of opinion and expression; = this
right includes freedom to hold opinions without interference and to
seek, receive and impart information and ideas through any media and
regardless of frontiers.

Article 20.
:=C2=A0 1 Everyone has the right to freedom of peaceful assembly and associ= ation.
:=C2=A0 2 No one may be compelled to belong to an association.


Theory
--------------

When looking at protocols the considerations can apply from several
perspectives.

+=C2=A0 =C2=A0The protocol's direct effects on human rights on the Inte= rnet.
+=C2=A0 =C2=A0The protocol's direct effect=C2=A0 on human rights in com= bination with
other protocols
+=C2=A0 =C2=A0The effect of specific protocol elements, separately or in combination with other protocol elements on human rights on the Internet +=C2=A0 =C2=A0The ability to determine when various effects are occurring, = i.e.
transparency
+=C2=A0 =C2=A0The effect of deployment or non deployment.=C2=A0 While this = may be may
seem beyond the protocol itself, often the design of protocol, its
difficulty in implementation and the degree to which it contains
required elements, poison pills or other protocol artifacts that either
encourage or discourse implementation or deployment can be significant
in the overall human rights affect of a protocol.


Other relevant research
-------------------------

Look at some of the academic research on the topic including David Post, Jonathan Zittrain and Laura Denardis, among others.

=E2=80=8BPerhaps also add Alexander Galloway'= ;s "Protocol"? and some of the work of Ian Brown?=E2=80=8B
=C2=A0
Methodology
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Currently defined in detail in draft-varon-hrpc-methodolgy to be folded
in at appropriate time.=C2=A0 this will largely be a reproduction of Sectio= n
3 of that document that focuses on the methodology

Briefly methodology has included:
+ scoping the research problem
- determining terminology to be use linking engineering and human rights concepts
- establishing methodology
- case studies on a set of protocols
- derivation of possible considerations

Case Studies
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In each of the case studies, the behavior of the protocols is analysed
for its positive and negative effects.=C2=A0 In some case these effects are=
due to the design of the protocol itself, in others they are due to
existing or absent features.

Early versions of the analysis on the following protocols are currently
being discussed on HRPC list.=C2=A0 Once the discussions have matured those=
discussions will be folded in this section.

DNS
--------------

Text being done by Will Scott on the HRPC list.

IP
--------------

Text being done by Will Scott on HRPC list.

HTTP
-------------

Text being done by Nex / Claudio on HRPC list.

XMPP
-------------

Text being done by Will Scott on HRPC list.

P2P
-------------

Text being done by Nex on HRPC List.


Possible areas for protocol considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The case studies point to several areas of protocol behavior that may be appropriate for considerations:

+ Character encoding for internationalization
- DNS Record
=C2=A0 - Distortion
=C2=A0 - Injection
=C2=A0 - Removal
- Network Poisoning
- Traffic
=C2=A0 - Interception
=C2=A0 - Manipulation
=C2=A0 - Throttling
- User Identification
=C2=A0 - Source and Destination visibility
=C2=A0 - Tracking

Additionally, discussion of the rights themselves and the evidence of
these rights being implicits in the IETF design principles {{clark}} and in some of the existing architecture and protocols {{Cath}}
{{Liddicoat}}, suggest other considerations.

Next Steps
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Once the first take at consideration are defined, what are the next
steps for creating something that can be sesable for protocol designers
and implementers in considering freedom of expression and and freedom of association in their work.

Acknowledgement
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A section that include the many contributors of text as as commenters
and those who are assisitng this project in existing.

IANA considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There shouldn't be any.

Security Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There shouldn't be any.

---

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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



--


'The management of normality is hard work'

<= /div>
--089e01681c56d7190e0522266951-- From nobody Fri Oct 16 05:30:54 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDB1AC3B1 for ; Fri, 16 Oct 2015 05:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGWbto5SzjL6 for ; Fri, 16 Oct 2015 05:30:51 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910B51AC3B4 for ; Fri, 16 Oct 2015 05:30:50 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 9B4D5CC03D for ; Fri, 16 Oct 2015 12:30:49 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 8BB6FCC03E for ; Fri, 16 Oct 2015 12:30:49 +0000 (UTC) Received: from [192.168.0.113] (dhcp-077-251-015-176.chello.nl [77.251.15.176]) by mail.article19.io (Postfix) with ESMTPSA id 7F10ACC03D for ; Fri, 16 Oct 2015 12:30:49 +0000 (UTC) Message-ID: <5620EDF5.8010106@article19.org> Date: Fri, 16 Oct 2015 14:30:45 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [hrpc] New methodology & glossary published -01 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:30:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 As always, comments are very welcome. Best, Niels PS Am aware that the document says it's expired (even though the expiry date is April 18, 2016), I already informed the secretariat about this. - -- Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWIO31AAoJEAi1oPJjbWjpN28H/i7WyjRYLW8YophQ16yfTcdx vi930UP7FsN1sAkiXiAPwaDNGVOVlST0hk3kQ5XrtBmyCcuGIi8IRFaT5a9IJrpG 13vFhwFx0/nPJVg7sZWXRUDGoNE/URMyLXRZbNvKmJ+zxLZLTd+ift8JUn5CfRPk nX60BZAkiOLeFC1+Xnfpx5oyg6oqUkRdO1EYQOnecLzMYzhRUtvaIFGwdMJIhMws LQsdFdOXbrHUMTptzXNPUQPpWc+NyxL605BT+Mr3Ytlq1Zrt082YQDRv+BsFhGTD RF5f+x6fXvhk7XfrJtYT7w/cdgZGl2tLsBgqEIUeEpMv/qN90A9ev9qgDR9+YNE= =0/Us -----END PGP SIGNATURE----- From nobody Fri Oct 16 07:54:39 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C11B2F3B for ; Fri, 16 Oct 2015 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tojef6tuVKI for ; Fri, 16 Oct 2015 07:54:35 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E5E1B2E93 for ; Fri, 16 Oct 2015 07:54:35 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A4ACB2801B2; Fri, 16 Oct 2015 16:54:33 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 9F8D128019B; Fri, 16 Oct 2015 16:54:33 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 92FC74C000F; Fri, 16 Oct 2015 16:54:03 +0200 (CEST) Date: Fri, 16 Oct 2015 16:54:03 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151016145403.GA11097@nic.fr> References: <5620EDF5.8010106@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5620EDF5.8010106@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: [hrpc] draft-varon-hrpc-methodology-01 DNS X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 14:54:37 -0000 On Fri, Oct 16, 2015 at 02:30:45PM +0200, Niels ten Oever wrote a message of 41 lines which said: > https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 The draft says "The second form occurs through the use of deep packet inspection, where all DNS protocol messages are inspected by the network, and objectionable content is distorted, as in [turkey]." But the article it references never mentions in-network DPI. As far as I know, in Turkey, it was always through lying resolvers that censorship was implemented. Also "The DNS system is organized around a set of independently operated 'Root Servers' run by organizations around the web" Are we talking of the Internet or the Web? Also, the DNS is certainly not organized around the root servers. From nobody Fri Oct 16 07:59:05 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD921B3069 for ; Fri, 16 Oct 2015 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7BeXT1Hyz04 for ; Fri, 16 Oct 2015 07:59:03 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5CA1B3081 for ; Fri, 16 Oct 2015 07:59:02 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 032552801B2; Fri, 16 Oct 2015 16:59:01 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id F280F28019B; Fri, 16 Oct 2015 16:59:00 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id E68AB4C000F; Fri, 16 Oct 2015 16:58:30 +0200 (CEST) Date: Fri, 16 Oct 2015 16:58:30 +0200 From: Stephane Bortzmeyer To: Will Scott Message-ID: <20151016145830.GA11694@nic.fr> References: <20151012120421.GD2465@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] cases - IP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 14:59:04 -0000 On Wed, Oct 14, 2015 at 08:33:37AM -0700, Will Scott wrote a message of 165 lines which said: > I've updated this section, the patch can be seen here: > https://github.com/nllz/IRTF-HRPC/compare/master...willscott:abdcc13?expand=1 The patch is empty "There isn’t anything to compare. nllz:master is up to date with all commits from willscott:abdcc13. Try switching the base for your comparison." draft-varon-hrpc-methodology-01 still uses the very same text (that I find objectionable) about mobility and multicasting. From nobody Fri Oct 16 08:02:10 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706B31B30DD for ; Fri, 16 Oct 2015 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se3r-CsviLix for ; Fri, 16 Oct 2015 08:02:07 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780691B30DA for ; Fri, 16 Oct 2015 08:02:07 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E25E52801B2; Fri, 16 Oct 2015 17:02:05 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id DD51528019B; Fri, 16 Oct 2015 17:02:05 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id D24914C000F; Fri, 16 Oct 2015 17:01:35 +0200 (CEST) Date: Fri, 16 Oct 2015 17:01:35 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151016150135.GB11694@nic.fr> References: <5620EDF5.8010106@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5620EDF5.8010106@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: [hrpc] draft-varon-hrpc-methodology-01 XMPP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 15:02:08 -0000 On Fri, Oct 16, 2015 at 02:30:45PM +0200, Niels ten Oever wrote a message of 41 lines which said: > https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 The XMPP section did not change since the drafts-of-drafts which were posted here. I regret it (the internationalisation section is especially confusing). From nobody Fri Oct 16 08:20:18 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14C1B314F for ; Fri, 16 Oct 2015 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgHQllA8qpsz for ; Fri, 16 Oct 2015 08:20:07 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76B01B313A for ; Fri, 16 Oct 2015 08:19:56 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2EC362801B2; Fri, 16 Oct 2015 17:19:55 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 29DD228019B; Fri, 16 Oct 2015 17:19:55 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 277C44C0029; Fri, 16 Oct 2015 17:19:25 +0200 (CEST) Date: Fri, 16 Oct 2015 17:19:25 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20151016151925.GA15376@nic.fr> References: <5620EDF5.8010106@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5620EDF5.8010106@article19.org> X-Operating-System: Debian GNU/Linux 8.2 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: [hrpc] Truth X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 15:20:11 -0000 On Fri, Oct 16, 2015 at 02:30:45PM +0200, Niels ten Oever wrote a message of 41 lines which said: > https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 > Authenticity The act of confirming the truth of an attribute of a > single piece of data or entity. I'm afraid that no technical protocol can establish the truth, which is a difficult philosophical concept. Technical protocols can prove, beyond a reasonable doubt, authenticity (the messages comes from the source it mentions) and integrity (noone tampered with the message) but it is not truth. I can write a message "Dinosaurs never existed" and sign it with PGP, it would not make it "the truth". So, I suggest: Authenticity : The fact that the data does indeed come from the source it claims to come from. (It is strongly linked with Integrity, see below). From nobody Fri Oct 16 20:44:43 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5DB1B2FB5 for ; Fri, 16 Oct 2015 20:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chsrxzPXDVac for ; Fri, 16 Oct 2015 20:44:41 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8C91B2FBC for ; Fri, 16 Oct 2015 20:44:41 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so25903406igb.0 for ; Fri, 16 Oct 2015 20:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mnjkrkOrBuy5vv5/H38wADpKkOrzbY2BFCko9Y8xoTU=; b=inTB5pZt1IETS2gYt1xOYTqqt/e0SzZLMEVe4jmPlpWha4i49QsplVNCQRMQIb4j67 yZNcRxH1EZvcrW0MvT4jXvlqrOXj2dxVARnxl+sbfKUgdj1DpCEljXQbciBPPw6OjlNR xH3khTUrpNPBFxw1yT8C8UcByobs9N0IKkaBo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mnjkrkOrBuy5vv5/H38wADpKkOrzbY2BFCko9Y8xoTU=; b=d8/0dG/rhiALxx+MLxZjsvpmE6E9u3WnorTTrRnvICJBAoBWXfetIt6yZhbEQbRaB8 bCtdcG9aDykJLgRJXz9PjNK8N/pRoRcJgd2TrNNRaTaaZ0sQccmh5JGdFN3AMUY7BrV0 PjFA4HbUQg6ZegpIe0on6fjCSFkacbXGwR3E45GqzD4bJQubaYYTlpo/p/iQQihitF8j c1GEVr2lRpO/VrInu+GzQIM+cutwXYGOtb8zZAfB2X7dFM2t/cSSk1EJrbVBgHfwz2tK abMLQPba8BluKCSBeGDuxuC99yOhRM5TpzEJO6/YwOW69sXLFlaJGPwG/pJyLBora6Wr F4rA== X-Gm-Message-State: ALoCoQldKES5LH7R5e6/K71ch53RPrBNNInv2g9zVWfdTFkwCo6oy/qIuy8+PzoKdIBzIF7Gw0Bs MIME-Version: 1.0 X-Received: by 10.50.65.74 with SMTP id v10mr9795253igs.54.1445053480755; Fri, 16 Oct 2015 20:44:40 -0700 (PDT) Received: by 10.50.252.42 with HTTP; Fri, 16 Oct 2015 20:44:40 -0700 (PDT) In-Reply-To: <20151016150135.GB11694@nic.fr> References: <5620EDF5.8010106@article19.org> <20151016150135.GB11694@nic.fr> Date: Fri, 16 Oct 2015 20:44:40 -0700 Message-ID: From: Will Scott To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=047d7b3a9b2c66f2e8052244bb2b Archived-At: Cc: Niels ten Oever , "hrpc@irtf.org" Subject: Re: [hrpc] draft-varon-hrpc-methodology-01 XMPP X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 03:44:42 -0000 --047d7b3a9b2c66f2e8052244bb2b Content-Type: text/plain; charset=UTF-8 Sorry for being delinquent on this. I've opened a pull request removing that section and cleaning up the text for XMPP https://github.com/nllz/IRTF-HRPC/pull/14 --Will On Fri, Oct 16, 2015 at 8:01 AM, Stephane Bortzmeyer wrote: > On Fri, Oct 16, 2015 at 02:30:45PM +0200, > Niels ten Oever wrote > a message of 41 lines which said: > > > https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 > > The XMPP section did not change since the drafts-of-drafts which were > posted here. I regret it (the internationalisation section is > especially confusing). > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --047d7b3a9b2c66f2e8052244bb2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for being delinquent on this.
I've opened a = pull request removing that section and cleaning up the text for XMPP
<= div>https://github.co= m/nllz/IRTF-HRPC/pull/14

--Will

On Fri, Oct 16, = 2015 at 8:01 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wro= te:
On Fri, Oct 16, 2015 at 02:30:45PM +0= 200,
=C2=A0Niels ten Oever <niels@arti= cle19.org> wrote
=C2=A0a message of 41 lines which said:

> https://tools.ietf.org/html/draft-va= ron-hrpc-methodology-01

The XMPP section did not change since the drafts-of-drafts which were
posted here. I regret it (the internationalisation section is
especially confusing).

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

--047d7b3a9b2c66f2e8052244bb2b-- From nobody Sat Oct 17 02:54:26 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE91A9238 for ; Sat, 17 Oct 2015 02:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUY-3gsRz4wi for ; Sat, 17 Oct 2015 02:54:23 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3531A9236 for ; Sat, 17 Oct 2015 02:54:21 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id E599C81C9; Sat, 17 Oct 2015 09:54:19 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id D3A4381CD; Sat, 17 Oct 2015 09:54:19 +0000 (UTC) Received: from [10.0.9.237] (unknown [77.241.230.246]) by mail.article19.io (Postfix) with ESMTPSA id 5EC0B81C9; Sat, 17 Oct 2015 09:54:18 +0000 (UTC) Message-ID: <56221AC9.9050101@article19.org> Date: Sat, 17 Oct 2015 11:54:17 +0200 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <5620EDF5.8010106@article19.org> <20151016151925.GA15376@nic.fr> In-Reply-To: <20151016151925.GA15376@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Truth X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 09:54:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks Stephane. I updated it on Github [0]. Monday I will push a new version of the ID, so all comments welcome until then so we can discuss them in Yokohama. Best, Niels [0] https://github.com/nllz/IRTF-HRPC/blob/master/draft-glossary.md Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 10/16/2015 05:19 PM, Stephane Bortzmeyer wrote: > On Fri, Oct 16, 2015 at 02:30:45PM +0200, Niels ten Oever > wrote a message of 41 lines which said: > >> https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 > >> Authenticity The act of confirming the truth of an attribute of >> a single piece of data or entity. > > I'm afraid that no technical protocol can establish the truth, > which is a difficult philosophical concept. Technical protocols can > prove, beyond a reasonable doubt, authenticity (the messages comes > from the source it mentions) and integrity (noone tampered with the > message) but it is not truth. > > I can write a message "Dinosaurs never existed" and sign it with > PGP, it would not make it "the truth". > > So, I suggest: > > Authenticity : The fact that the data does indeed come from the > source it claims to come from. (It is strongly linked with > Integrity, see below). > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWIhrJAAoJEAi1oPJjbWjpdd8IAKcyldKYxESJMnjrzsdpdobV zvEAlAjRitIVDNMs5JxwfKBL6DWQPhhuG/YVyRJLm6i8/du0albbm9/2PXwcgGmJ y53tsdwSLZPoXY2U1eNLP7C1Jra0FKU+AWT5cvsu+AWaK39jW3sJ21r/HzAW7h7q U7pxeICe37xUXF5rX6pAEVlb6K1oY3FTBVDnRT+cBlEXwcRSt9vKgi/X8xJ48CUD 2Xy4Dh1DMy29KFNzbvsfPFfnTaW9w+LEw+RORDaJfbOpsGpbmAcqlsRbKUXAjadH ZmYVC8q/KX05rnDrlqR8nWWedk6LQWIWro7/xsVe+7wpMoXLpIopOEhcdnXMmRs= =v9qA -----END PGP SIGNATURE----- From nobody Sun Oct 18 03:42:29 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E801C1B2ED9 for ; Sun, 18 Oct 2015 03:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGus6MWaVS19 for ; Sun, 18 Oct 2015 03:42:26 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 673E11B2ECD for ; Sun, 18 Oct 2015 03:42:26 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t9IAgNJa025986 for ; Sun, 18 Oct 2015 06:42:23 -0400 Received: (qmail 29569 invoked by uid 0); 18 Oct 2015 10:42:23 -0000 X-TCPREMOTEIP: 199.91.193.230 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@199.91.193.230) by 0 with ESMTPA; 18 Oct 2015 10:42:23 -0000 References: <20151018103854.24284.56706.idtracker@ietfa.amsl.com> To: hrpc@irtf.org From: Avri Doria Organization: Technicalities X-Forwarded-Message-Id: <20151018103854.24284.56706.idtracker@ietfa.amsl.com> Message-ID: <5623778E.8030307@acm.org> Date: Sun, 18 Oct 2015 11:42:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151018103854.24284.56706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 151017-1, 10/17/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] Fwd: New Version Notification for draft-doria-hrpc-report-00.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 10:42:28 -0000 -------- Forwarded Message -------- Subject: New Version Notification for draft-doria-hrpc-report-00.txt Date: Sun, 18 Oct 2015 03:38:54 -0700 From: internet-drafts@ietf.org To: Avri Doria , Avri Doria A new version of I-D, draft-doria-hrpc-report-00.txt has been successfully submitted by Avri Doria and posted to the IETF repository. Name: draft-doria-hrpc-report Revision: 00 Title: Human Rights Protocol Considerations - Report Document date: 2015-10-18 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-doria-hrpc-report-00.txt Status: https://datatracker.ietf.org/doc/draft-doria-hrpc-report/ Htmlized: https://tools.ietf.org/html/draft-doria-hrpc-report-00 Abstract: This document present an overview of the project to map engineering concepts at the protocol level that may be related to promotion and protection of the freedom of expression and association. This first draft is intended to provide the framework for reporting on the study, initial results and basic considerations. At a later stage it will fold in the work being done in the Methodology and Glossary drafts as well as the work being done in the case studies. It also folds in some of the text included in the original proposal for the HRPC. Discussion on this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/admindb/hrpc Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Mon Oct 19 02:18:00 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB01A8737 for ; Mon, 19 Oct 2015 02:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSAMAtwvAb1J for ; Mon, 19 Oct 2015 02:17:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28311A87A5 for ; Mon, 19 Oct 2015 02:17:56 -0700 (PDT) Received: from usca1cl-l3fa362.sanmateo.corp.akamai.com (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 68A2D22E1F4; Mon, 19 Oct 2015 05:17:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham Date: Mon, 19 Oct 2015 20:17:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> To: hrpc@irtf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Stephen Farrell Subject: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:17:59 -0000 FYI.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-for-the-users-02.txt > Date: 19 October 2015 8:17:21 pm AEDT > To: "Mark Nottingham" , "Mark Nottingham" = >=20 >=20 > A new version of I-D, draft-nottingham-for-the-users-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-for-the-users > Revision: 02 > Title: The Internet is for End Users > Document date: 2015-10-19 > Group: Individual Submission > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-02.txt= > Status: = https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-for-the-users-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-for-the-users-02 >=20 > Abstract: > Internet standards serve and are used by a variety of communities. > This document contains guidelines for explicitly identifying them, > serving them, and determining how to resolve conflicts between their > interests, when necessary. >=20 > It also motivates considering end users as the highest priority > concern for Internet standards. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 19 04:37:56 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185851A8AD3 for ; Mon, 19 Oct 2015 04:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiXr3rxgS_yQ for ; Mon, 19 Oct 2015 04:37:52 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC3F1A8ACB for ; Mon, 19 Oct 2015 04:37:51 -0700 (PDT) Received: by wijp11 with SMTP id p11so1278739wij.0 for ; Mon, 19 Oct 2015 04:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=21g6eu6ONCI5o5sjQHenXEt/6eSAhxw9JiywwM13R80=; b=K8UtnbB815yQuKANw+YLdebXRK81c60JR0tFrHZfnJFPQXSzFsb5GgupsH8GfnipZN vMtURI81xOCJZ4IB1R8Vgp+P8zUIOFkp4+fezMnCyxPIAchJU6MtlRBqm6cBCAzA8j4D oSn5Yy+GVjqvAn9zWjuqASun5sQ7GKzqAR5CFYXbk/Hn6bSkFpc8Syvo75Tzq6M4oB7m ElIqQBSGoFqsg/yDzxGC1pplM1WjzYZfjVUxeQMGxABwgFHE8QO7Bgz5AUV+2IR8J6Sv 4vksN7Li5AEqi1QY0S20lnM8HygTjoUZms1vroyLVnuf1BMpQh/u8euWFTwO67y2z/ye ztBg== MIME-Version: 1.0 X-Received: by 10.180.34.38 with SMTP id w6mr18150350wii.78.1445254670335; Mon, 19 Oct 2015 04:37:50 -0700 (PDT) Received: by 10.194.30.200 with HTTP; Mon, 19 Oct 2015 04:37:50 -0700 (PDT) In-Reply-To: <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> Date: Mon, 19 Oct 2015 12:37:50 +0100 Message-ID: From: Corinne Cath To: Mark Nottingham Content-Type: multipart/alternative; boundary=e89a8f839d693c457e052273934e Archived-At: Cc: hrpc@irtf.org, Stephen Farrell Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 11:37:54 -0000 --e89a8f839d693c457e052273934e Content-Type: text/plain; charset=UTF-8 nice! thanks for sharing. On Mon, Oct 19, 2015 at 10:17 AM, Mark Nottingham wrote: > FYI. > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-nottingham-for-the-users-02.txt > > Date: 19 October 2015 8:17:21 pm AEDT > > To: "Mark Nottingham" , "Mark Nottingham" > > > > > > A new version of I-D, draft-nottingham-for-the-users-02.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Name: draft-nottingham-for-the-users > > Revision: 02 > > Title: The Internet is for End Users > > Document date: 2015-10-19 > > Group: Individual Submission > > Pages: 9 > > URL: > https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-02.txt > > Status: > https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ > > Htmlized: > https://tools.ietf.org/html/draft-nottingham-for-the-users-02 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 > > > > Abstract: > > Internet standards serve and are used by a variety of communities. > > This document contains guidelines for explicitly identifying them, > > serving them, and determining how to resolve conflicts between their > > interests, when necessary. > > > > It also motivates considering end users as the highest priority > > concern for Internet standards. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- 'The management of normality is hard work' --e89a8f839d693c457e052273934e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
nice! thanks for sharing.

On Mon, Oct 19, 2015 at 10:17 AM, Mark Nott= ingham <mnot@mnot.net> wrote:
= FYI.


> Begin forwarded message:
>
> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-nottingham-for-the-users-0= 2.txt
> Date: 19 October 2015 8:17:21 pm AEDT
> To: "Mark Nottingham" <m= not@mnot.net>, "Mark Nottingham" <mnot@mnot.net>
>
>
> A new version of I-D, draft-nottingham-for-the-users-02.txt
> has been successfully submitted by Mark Nottingham and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nottingham-for-the-users<= br> > Revision:=C2=A0 =C2=A0 =C2=A002
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Inte= rnet is for End Users
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-10-19
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-notting= ham-for-the-users-02.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-nottingham-for-the-users= /
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-nottingham-for-the-users-02
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-fo= r-the-users-02
>
> Abstract:
>=C2=A0 =C2=A0Internet standards serve and are used by a variety of comm= unities.
>=C2=A0 =C2=A0This document contains guidelines for explicitly identifyi= ng them,
>=C2=A0 =C2=A0serving them, and determining how to resolve conflicts bet= ween their
>=C2=A0 =C2=A0interests, when necessary.
>
>=C2=A0 =C2=A0It also motivates considering end users as the highest pri= ority
>=C2=A0 =C2=A0concern for Internet standards.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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



--


'The management of normality is hard work'

<= /div>
--e89a8f839d693c457e052273934e-- From nobody Mon Oct 26 05:58:17 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3403A1B2E49 for ; Mon, 26 Oct 2015 05:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.323 X-Spam-Level: ** X-Spam-Status: No, score=2.323 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjtjbQJjLyIA for ; Mon, 26 Oct 2015 05:58:14 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196A61B2E44 for ; Mon, 26 Oct 2015 05:58:13 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 233C01A003C for ; Mon, 26 Oct 2015 12:58:12 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 13B231A003D for ; Mon, 26 Oct 2015 12:58:12 +0000 (UTC) Received: from [192.168.43.18] (unknown [62.72.192.101]) by mail.article19.io (Postfix) with ESMTPSA id D153B1A003C for ; Mon, 26 Oct 2015 12:58:11 +0000 (UTC) Message-ID: <562E2362.7020909@article19.org> Date: Mon, 26 Oct 2015 13:58:10 +0100 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hrpc] agenda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 12:58:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, Please find underneath a refined version of the agenda for our meeting in Yokohama. All comments / suggestions / ideas are very welcome. Best, Niels - - Beginning (5 min) Agenda Bashing Jabber scribe, note takers Notewell Introduction - - Status of proposed research group (5 min) - - Context of research (10 Min) - - Discussion of 'A Case Study of Coding Rights' (20 min) https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf - - Discussion of Methodology draft (30 min) https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 Cases IP DNS HTTP P2P XMPP VPN Definitions Way forward - - Discussion of Glossary draft (10 min) https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 - - Discussion of report draft (10 min) https://tools.ietf.org/html/draft-doria-hrpc-report-00 - - Open discussion other drafts, papers, ideas (20 min) - - Charter update status (if necessary - 5 Min) - - Next steps (5 min) - - AOB - -- Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWLiNiAAoJEAi1oPJjbWjp6F8H/ituWRPOIp/kLnv6VQ2g3Ff6 dwS9kodSEzdv/Jgp9gQX7U6OIo3LpspZ4//gdxsIcc/S3LxpC/nJ4fAIMBUydduM bz/kvvK1SENWUGKeNOw8j9G1K88NHNM8MrHHGSomjYMPsumr1w92A5LF57S0sGG/ 1DtvZxRw+HQefSBvJtAiirZYOiFKVuxd69pvdXV6P6i/iqxU6vI0+GoM7jHLFtZU 97v6nE6vfMLr9vFDrjb/F+4y5ecHZorsQ3R+DljKdVgsLWU/KCVCaODZbdvlba4V aPSerJAKbR0o8+8vGOkBHLVhJEsnTPz7h6S92yOEdSiBLaL/KwcIBx+u5aTfW/0= =9y7Y -----END PGP SIGNATURE----- From nobody Mon Oct 26 09:52:46 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5B1A014B for ; Mon, 26 Oct 2015 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XhEf2TGGWA2 for ; Mon, 26 Oct 2015 09:52:42 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36041A014E for ; Mon, 26 Oct 2015 09:52:42 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 015B5141D2 for ; Mon, 26 Oct 2015 16:52:41 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id E50E7141EC for ; Mon, 26 Oct 2015 16:52:40 +0000 (UTC) Received: from [192.168.43.18] (unknown [62.72.192.101]) by mail.article19.io (Postfix) with ESMTPSA id B9608141D2 for ; Mon, 26 Oct 2015 16:52:40 +0000 (UTC) Message-ID: <562E5A58.5080502@article19.org> Date: Mon, 26 Oct 2015 17:52:40 +0100 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: hrpc@irtf.org References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> In-Reply-To: <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 16:52:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks Mark, will this draft be discussed in Yokohama? If so, in which session? If not, on which mailinglist/WG/track is this being discussed? Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 10/19/2015 11:17 AM, Mark Nottingham wrote: > FYI. > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org Subject: New Version Notification >> for draft-nottingham-for-the-users-02.txt Date: 19 October 2015 >> 8:17:21 pm AEDT To: "Mark Nottingham" , "Mark >> Nottingham" >> >> >> A new version of I-D, draft-nottingham-for-the-users-02.txt has >> been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name: draft-nottingham-for-the-users Revision: 02 Title: The >> Internet is for End Users Document date: 2015-10-19 Group: >> Individual Submission Pages: 9 URL: >> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-0 2.txt >> >> Status: https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >> Htmlized: >> https://tools.ietf.org/html/draft-nottingham-for-the-users-02 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 >> >> >> Abstract: >> Internet standards serve and are used by a variety of >> communities. This document contains guidelines for explicitly >> identifying them, serving them, and determining how to resolve >> conflicts between their interests, when necessary. >> >> It also motivates considering end users as the highest priority >> concern for Internet standards. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> > > -- Mark Nottingham https://www.mnot.net/ > > _______________________________________________ hrpc mailing list > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWLlpYAAoJEAi1oPJjbWjpImYH/jDsooPGYtDQQ+1chIZSFy8L ckob5QkvV+eI8r4dfEJEctTkEn3lFFLG+I+x55s+hrJF7pCQSA9Q+a6Fr1kAZjCk IeoL+zrDfM+q7WLbfAjjdSlwSE+zhjE+8jDgioY8j2HCQ5F1mWW07yv50I7mBiJt liM8pDND0vjYZzx5OxC/+hU7G8/KcDED8uqp1xMIU8X7yUMe6YY6sSfIpLB4Gmch fAQpv3rbaWqcfEGG9M7yX8dLL2ZKun0AJUZ9YCPNivwe1OBBUcPtL1kPgpFDfxaD lsEEgcDqNUVKz9uSNaixNfO7UFqC3eRNflOy8Xev6NXgxjuZgvowOnjCtjyRTeM= =/uDJ -----END PGP SIGNATURE----- From nobody Thu Oct 29 01:32:24 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E3B1B2AF0 for ; Thu, 29 Oct 2015 01:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZFicxWDkpAG for ; Thu, 29 Oct 2015 01:32:20 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997011B2AC8 for ; Thu, 29 Oct 2015 01:32:19 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 064B3124034 for ; Thu, 29 Oct 2015 08:32:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id EA544124032 for ; Thu, 29 Oct 2015 08:32:17 +0000 (UTC) Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EHOJcjazg0GP for ; Thu, 29 Oct 2015 08:32:17 +0000 (UTC) Received: from [145.18.161.96] (wcw-staff-145-18-161-96.wireless.uva.nl [145.18.161.96]) by mail.article19.io (Postfix) with ESMTPSA id BE5EC124031 for ; Thu, 29 Oct 2015 08:32:17 +0000 (UTC) Message-ID: <5631D990.1010505@article19.org> Date: Thu, 29 Oct 2015 09:32:16 +0100 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" References: <4E6AF9C2-9113-4541-BF86-0241C1B03A7C@ietf.org> In-Reply-To: <4E6AF9C2-9113-4541-BF86-0241C1B03A7C@ietf.org> X-Forwarded-Message-Id: <4E6AF9C2-9113-4541-BF86-0241C1B03A7C@ietf.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hrpc] Fwd: Screening film 'Net of Rights' ahead of plenary X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 08:32:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI - -------- Forwarded Message -------- Subject: Screening film 'Net of Rights' ahead of plenary Date: Thu, 29 Oct 2015 09:41:10 +0900 From: IETF Chair Reply-To: 94attendees@ietf.org To: 94all@ietf.org CC: 94attendees@ietf.org, Niels ten Oever Members of the proposed IRTF research group on human rights protocol considerations (HRPC), conducted interviews at the IETF92 meeting in Dallas to improve the groups understanding on the views held in the IETF community on the relation between human rights and Internet protocols. These interviews have now been edited into a film. This film which will premiere at IETF94, where it will be shown ahead of the plenary during the 15:00-15:30 break. There will also be a few minutes for Q&A. You are all very much invited to come and watch the screening. The location is rooms 301-304. Jari Arkko, IETF Chair and Niels ten Oever, Article 19 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWMdmQAAoJEAi1oPJjbWjp270IAJonlkV0kxO+VHe0W7AfxwOQ HsHS4WfU0saieiyau+KSOPIsA5DZESooWXPxpbOD60neAUqZIJV80SZx8xbbiur0 KdFcMVrdaxCbrN6u2KNysIIE5+KsCkD9JNyrhAWxXK3BJ/GMCOHUOqivYMqKNJE6 Dma3lq/m7cAFoeimGheJT/1MrR1KE0DnFbe7a0dHiI6/nxcwTBUImr8utCwZ3c79 3wObjXb/gJVNsE2FTdAbjX/I3BZvgkcLZ4fd4FIog8PFuCSS3Vd1MrpM6tjbU12L o17MJICVRWwj15N/JvSgj4/qTLqssSmLr3HEZdFUDySGI2QSibvCMnOUxbiOTmk= =5Mf2 -----END PGP SIGNATURE----- From nobody Thu Oct 29 20:28:02 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C21B35B4 for ; Thu, 29 Oct 2015 20:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ3kHQrTeXcg for ; Thu, 29 Oct 2015 20:27:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518F61B35AD for ; Thu, 29 Oct 2015 20:27:58 -0700 (PDT) Received: from [100.64.26.228] (unknown [210.227.101.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C7FDC22E200; Thu, 29 Oct 2015 23:27:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <562E5A58.5080502@article19.org> Date: Fri, 30 Oct 2015 12:27:48 +0900 Content-Transfer-Encoding: 7bit Message-Id: <242A8B6C-39F5-4939-858C-A4F0A5DC6E89@mnot.net> References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> <562E5A58.5080502@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.2104) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 03:28:01 -0000 Hey, I can talk about this draft if there's time. Cheers, > On 27 Oct 2015, at 1:52 am, Niels ten Oever wrote: > > Signed PGP part > Thanks Mark, will this draft be discussed in Yokohama? If so, in which > session? If not, on which mailinglist/WG/track is this being discussed? > > Best, > > Niels > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 10/19/2015 11:17 AM, Mark Nottingham wrote: > > FYI. > > > > > >> Begin forwarded message: > >> > >> From: internet-drafts@ietf.org Subject: New Version Notification > >> for draft-nottingham-for-the-users-02.txt Date: 19 October 2015 > >> 8:17:21 pm AEDT To: "Mark Nottingham" , "Mark > >> Nottingham" > >> > >> > >> A new version of I-D, draft-nottingham-for-the-users-02.txt has > >> been successfully submitted by Mark Nottingham and posted to the > >> IETF repository. > >> > >> Name: draft-nottingham-for-the-users Revision: 02 Title: The > >> Internet is for End Users Document date: 2015-10-19 Group: > >> Individual Submission Pages: 9 URL: > >> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-0 > 2.txt > >> > >> > Status: > https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-nottingham-for-the-users-02 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 > >> > >> > >> > Abstract: > >> Internet standards serve and are used by a variety of > >> communities. This document contains guidelines for explicitly > >> identifying them, serving them, and determining how to resolve > >> conflicts between their interests, when necessary. > >> > >> It also motivates considering end users as the highest priority > >> concern for Internet standards. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> The IETF Secretariat > >> > > > > -- Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ hrpc mailing list > > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 30 02:28:27 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541E81A89F9 for ; Fri, 30 Oct 2015 02:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtwhFNNQ-Pza for ; Fri, 30 Oct 2015 02:28:24 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C340B1A89F6 for ; Fri, 30 Oct 2015 02:28:22 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 79EBF124033; Fri, 30 Oct 2015 09:28:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 66925124032; Fri, 30 Oct 2015 09:28:21 +0000 (UTC) Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H1wa1yiz5CzH; Fri, 30 Oct 2015 09:28:21 +0000 (UTC) Received: from [192.168.1.67] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 2A160124031; Fri, 30 Oct 2015 09:28:21 +0000 (UTC) Message-ID: <56333834.30607@article19.org> Date: Fri, 30 Oct 2015 10:28:20 +0100 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Mark Nottingham References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> <562E5A58.5080502@article19.org> <242A8B6C-39F5-4939-858C-A4F0A5DC6E89@mnot.net> In-Reply-To: <242A8B6C-39F5-4939-858C-A4F0A5DC6E89@mnot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 09:28:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There is time on the agenda (see below), but I thought you mentioned earlier you had a bof at the same time. If not, more than happy to add you and the draft to the agenda. - - Beginning (5 min) Agenda Bashing Jabber scribe, note takers Notewell Introduction - - Status of proposed research group (5 min) - - Context of research (10 Min) - - Discussion of 'A Case Study of Coding Rights' (20 min) https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf - - Discussion of Methodology draft (30 min) https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 Cases IP DNS HTTP P2P XMPP VPN Definitions Way forward - - Discussion of Glossary draft (10 min) https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 - - Discussion of report draft (10 min) https://tools.ietf.org/html/draft-doria-hrpc-report-00 - - Open discussion other drafts, papers, ideas (20 min) - - Charter update status (if necessary - 5 Min) - - Next steps (5 min) - - AOB Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 10/30/2015 04:27 AM, Mark Nottingham wrote: > Hey, > > I can talk about this draft if there's time. > > Cheers, > > >> On 27 Oct 2015, at 1:52 am, Niels ten Oever >> wrote: >> >> Signed PGP part Thanks Mark, will this draft be discussed in >> Yokohama? If so, in which session? If not, on which >> mailinglist/WG/track is this being discussed? >> >> Best, >> >> Niels >> >> Niels ten Oever Head of Digital >> >> Article 19 www.article19.org >> >> PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D >> 68E9 >> >> On 10/19/2015 11:17 AM, Mark Nottingham wrote: >>> FYI. >>> >>> >>>> Begin forwarded message: >>>> >>>> From: internet-drafts@ietf.org Subject: New Version >>>> Notification for draft-nottingham-for-the-users-02.txt Date: >>>> 19 October 2015 8:17:21 pm AEDT To: "Mark Nottingham" >>>> , "Mark Nottingham" >>>> >>>> >>>> A new version of I-D, draft-nottingham-for-the-users-02.txt >>>> has been successfully submitted by Mark Nottingham and posted >>>> to the IETF repository. >>>> >>>> Name: draft-nottingham-for-the-users Revision: 02 Title: >>>> The Internet is for End Users Document date: 2015-10-19 >>>> Group: Individual Submission Pages: 9 URL: >>>> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users - -0 >> >>>> 2.txt >>>> >>>> >> Status: >> https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-nottingham-for-the-users-02 >>>> >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 >>>> >>>> >>>> >> >>>> Abstract: >>>> Internet standards serve and are used by a variety of >>>> communities. This document contains guidelines for >>>> explicitly identifying them, serving them, and determining >>>> how to resolve conflicts between their interests, when >>>> necessary. >>>> >>>> It also motivates considering end users as the highest >>>> priority concern for Internet standards. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the >>>> time of submission until the htmlized version and diff are >>>> available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> >>> -- Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ hrpc mailing >>> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >>> >> >> >> _______________________________________________ hrpc mailing >> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > > -- Mark Nottingham https://www.mnot.net/ > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWMzg0AAoJEAi1oPJjbWjp+2UH/AjdcBA8s1h/J+ieLiPY1Ul3 d7Krz1uirQVhm5y6VN4YKHA11Ka8u3HR8eU7GqY7DRNZC4fgvMoASxSrfkj+f8d6 DHmgASqXpk7eiD1BiHsl4rTXFMTKM0IiPEutUJ5Qe8M/AN+/0h7+S8aUHWCLV+i+ yvQv49+aCiSkYfLLIzJ1LFP5kgrJWoBQ7Nti/bW8WbmMMJdF/Fl2Xh0tntSrn7T7 s0MRHxIZF2YvK75b4BTvX/tmB0ISPgxIYgnZGMzwQ/VUMfU7w3SqBKTgaEzGmsO+ znn2Uzdq96KX2hbo4Y77WtORxs42qNkILRiV1+5hMGzDcLz3QcRQ8QeThRe4cUU= =+tfP -----END PGP SIGNATURE----- From nobody Fri Oct 30 16:58:43 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8681B3CAB for ; Fri, 30 Oct 2015 16:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xfqDNXXzzKo for ; Fri, 30 Oct 2015 16:58:39 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5901B3CA1 for ; Fri, 30 Oct 2015 16:58:36 -0700 (PDT) Received: from [10.71.0.171] (unknown [182.171.73.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2B998509BD; Fri, 30 Oct 2015 19:58:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <56333834.30607@article19.org> Date: Sat, 31 Oct 2015 08:58:30 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> <562E5A58.5080502@article19.org> <242A8B6C-39F5-4939-858C-A4F0A5DC6E89@mnot.net> <56333834.30607@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.2104) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 23:58:41 -0000 I've shifted things around. Thanks! > On 30 Oct 2015, at 6:28 pm, Niels ten Oever wrote: > > Signed PGP part > There is time on the agenda (see below), but I thought you mentioned > earlier you had a bof at the same time. If not, more than happy to add > you and the draft to the agenda. > > - Beginning (5 min) > Agenda Bashing > Jabber scribe, note takers > Notewell > Introduction > - Status of proposed research group (5 min) > - Context of research (10 Min) > - Discussion of 'A Case Study of Coding Rights' (20 min) > https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf > - Discussion of Methodology draft (30 min) > https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 > Cases > IP > DNS > HTTP > P2P > XMPP > VPN > Definitions > Way forward > - Discussion of Glossary draft (10 min) > https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 > - Discussion of report draft (10 min) > https://tools.ietf.org/html/draft-doria-hrpc-report-00 > - Open discussion other drafts, papers, ideas (20 min) > - Charter update status (if necessary - 5 Min) > - Next steps (5 min) > - AOB > > Best, > > Niels > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 10/30/2015 04:27 AM, Mark Nottingham wrote: > > Hey, > > > > I can talk about this draft if there's time. > > > > Cheers, > > > > > >> On 27 Oct 2015, at 1:52 am, Niels ten Oever > >> wrote: > >> > >> Signed PGP part Thanks Mark, will this draft be discussed in > >> Yokohama? If so, in which session? If not, on which > >> mailinglist/WG/track is this being discussed? > >> > >> Best, > >> > >> Niels > >> > >> Niels ten Oever Head of Digital > >> > >> Article 19 www.article19.org > >> > >> PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D > >> 68E9 > >> > >> On 10/19/2015 11:17 AM, Mark Nottingham wrote: > >>> FYI. > >>> > >>> > >>>> Begin forwarded message: > >>>> > >>>> From: internet-drafts@ietf.org Subject: New Version > >>>> Notification for draft-nottingham-for-the-users-02.txt Date: > >>>> 19 October 2015 8:17:21 pm AEDT To: "Mark Nottingham" > >>>> , "Mark Nottingham" > >>>> > >>>> > >>>> A new version of I-D, draft-nottingham-for-the-users-02.txt > >>>> has been successfully submitted by Mark Nottingham and posted > >>>> to the IETF repository. > >>>> > >>>> Name: draft-nottingham-for-the-users Revision: 02 Title: > >>>> The Internet is for End Users Document date: 2015-10-19 > >>>> Group: Individual Submission Pages: 9 URL: > >>>> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users > -0 > >> > >>>> > 2.txt > >>>> > >>>> > >> Status: > >> https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ > >>>> Htmlized: > >>>> https://tools.ietf.org/html/draft-nottingham-for-the-users-02 > >>>> > >>>> > Diff: > >>>> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 > >>>> > >>>> > >>>> > >> > >>>> > Abstract: > >>>> Internet standards serve and are used by a variety of > >>>> communities. This document contains guidelines for > >>>> explicitly identifying them, serving them, and determining > >>>> how to resolve conflicts between their interests, when > >>>> necessary. > >>>> > >>>> It also motivates considering end users as the highest > >>>> priority concern for Internet standards. > >>>> > >>>> > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the > >>>> time of submission until the htmlized version and diff are > >>>> available at tools.ietf.org. > >>>> > >>>> The IETF Secretariat > >>>> > >>> > >>> -- Mark Nottingham https://www.mnot.net/ > >>> > >>> _______________________________________________ hrpc mailing > >>> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > >>> > >> > >> > >> _______________________________________________ hrpc mailing > >> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc > > > > -- Mark Nottingham https://www.mnot.net/ > > > > > > > > > -- Mark Nottingham https://www.mnot.net/ From nobody Sat Oct 31 08:42:37 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA31A6F84 for ; Sat, 31 Oct 2015 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHJqA8xzneJU for ; Sat, 31 Oct 2015 08:42:34 -0700 (PDT) Received: from atl4mhob19.myregisteredsite.com (atl4mhob19.myregisteredsite.com [209.17.115.112]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB31A6F86 for ; Sat, 31 Oct 2015 08:42:34 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob19.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t9VFgVJJ040131 for ; Sat, 31 Oct 2015 11:42:31 -0400 Received: (qmail 10925 invoked by uid 0); 31 Oct 2015 15:42:31 -0000 X-TCPREMOTEIP: 133.93.85.188 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@133.93.85.188) by 0 with ESMTPA; 31 Oct 2015 15:42:31 -0000 References: <20151019091721.19145.52317.idtracker@ietfa.amsl.com> <22346DA3-73AC-4BA7-99BC-DEF249E95E02@mnot.net> <562E5A58.5080502@article19.org> <242A8B6C-39F5-4939-858C-A4F0A5DC6E89@mnot.net> <56333834.30607@article19.org> To: hrpc@irtf.org From: Avri Doria Organization: Technicalities Message-ID: <5634E165.1020903@acm.org> Date: Sun, 1 Nov 2015 00:42:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 151031-0, 10/31/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] New Version Notification for draft-nottingham-for-the-users-02.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 15:42:36 -0000 Great! avri On 31-Oct-15 08:58, Mark Nottingham wrote: > I've shifted things around. Thanks! > >> On 30 Oct 2015, at 6:28 pm, Niels ten Oever wrote: >> >> Signed PGP part >> There is time on the agenda (see below), but I thought you mentioned >> earlier you had a bof at the same time. If not, more than happy to add >> you and the draft to the agenda. >> >> - Beginning (5 min) >> Agenda Bashing >> Jabber scribe, note takers >> Notewell >> Introduction >> - Status of proposed research group (5 min) >> - Context of research (10 Min) >> - Discussion of 'A Case Study of Coding Rights' (20 min) >> https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf >> - Discussion of Methodology draft (30 min) >> https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 >> Cases >> IP >> DNS >> HTTP >> P2P >> XMPP >> VPN >> Definitions >> Way forward >> - Discussion of Glossary draft (10 min) >> https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 >> - Discussion of report draft (10 min) >> https://tools.ietf.org/html/draft-doria-hrpc-report-00 >> - Open discussion other drafts, papers, ideas (20 min) >> - Charter update status (if necessary - 5 Min) >> - Next steps (5 min) >> - AOB >> >> Best, >> >> Niels >> >> Niels ten Oever >> Head of Digital >> >> Article 19 >> www.article19.org >> >> PGP fingerprint 8D9F C567 BEE4 A431 56C4 >> 678B 08B5 A0F2 636D 68E9 >> >> On 10/30/2015 04:27 AM, Mark Nottingham wrote: >>> Hey, >>> >>> I can talk about this draft if there's time. >>> >>> Cheers, >>> >>> >>>> On 27 Oct 2015, at 1:52 am, Niels ten Oever >>>> wrote: >>>> >>>> Signed PGP part Thanks Mark, will this draft be discussed in >>>> Yokohama? If so, in which session? If not, on which >>>> mailinglist/WG/track is this being discussed? >>>> >>>> Best, >>>> >>>> Niels >>>> >>>> Niels ten Oever Head of Digital >>>> >>>> Article 19 www.article19.org >>>> >>>> PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D >>>> 68E9 >>>> >>>> On 10/19/2015 11:17 AM, Mark Nottingham wrote: >>>>> FYI. >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> From: internet-drafts@ietf.org Subject: New Version >>>>>> Notification for draft-nottingham-for-the-users-02.txt Date: >>>>>> 19 October 2015 8:17:21 pm AEDT To: "Mark Nottingham" >>>>>> , "Mark Nottingham" >>>>>> >>>>>> >>>>>> A new version of I-D, draft-nottingham-for-the-users-02.txt >>>>>> has been successfully submitted by Mark Nottingham and posted >>>>>> to the IETF repository. >>>>>> >>>>>> Name: draft-nottingham-for-the-users Revision: 02 Title: >>>>>> The Internet is for End Users Document date: 2015-10-19 >>>>>> Group: Individual Submission Pages: 9 URL: >>>>>> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users >> -0 >> 2.txt >>>>>> >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-nottingham-for-the-users-02 >>>>>> >>>>>> >> Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-02 >>>>>> >>>>>> >>>>>> >> Abstract: >>>>>> Internet standards serve and are used by a variety of >>>>>> communities. This document contains guidelines for >>>>>> explicitly identifying them, serving them, and determining >>>>>> how to resolve conflicts between their interests, when >>>>>> necessary. >>>>>> >>>>>> It also motivates considering end users as the highest >>>>>> priority concern for Internet standards. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the >>>>>> time of submission until the htmlized version and diff are >>>>>> available at tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> -- Mark Nottingham https://www.mnot.net/ >>>>> >>>>> _______________________________________________ hrpc mailing >>>>> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >>>>> >>>> >>>> _______________________________________________ hrpc mailing >>>> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >>> -- Mark Nottingham https://www.mnot.net/ >>> >>> >>> >>> > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Sat Oct 31 21:44:30 2015 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4191B5E96 for ; Sat, 31 Oct 2015 21:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNHx8Zh7e7kD for ; Sat, 31 Oct 2015 21:44:26 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA961B5E92 for ; Sat, 31 Oct 2015 21:44:25 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 1AFCA124031 for ; Sun, 1 Nov 2015 04:44:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id F3975124032 for ; Sun, 1 Nov 2015 04:44:23 +0000 (UTC) Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VWQbg79OkDK5 for ; Sun, 1 Nov 2015 04:44:23 +0000 (UTC) Received: from [133.93.52.111] (dhcp-52-111.meeting.ietf94.jp [133.93.52.111]) by mail.article19.io (Postfix) with ESMTPSA id 9DAD2124031 for ; Sun, 1 Nov 2015 04:44:22 +0000 (UTC) Message-ID: <563598A2.1090602@article19.org> Date: Sun, 01 Nov 2015 05:44:18 +0100 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "hrpc@irtf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [hrpc] agenda hrpc tuesday 15:20-16:50 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 04:44:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, Please find underneath the updated agenda for our session on Tuesday 15:20-16:50. The only change is the addition of the discussion of the draft 'The Internet is for End Users' (yay). Best, Niels - - Beginning (5 min) Agenda Bashing Jabber scribe, note takers Notewell Introduction - - Status of proposed research group (5 min) - - Context of research (10 Min) - - Discussion of 'A Case Study of Coding Rights' (20 min) https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf - - Discussion of Methodology draft (30 min) https://tools.ietf.org/html/draft-varon-hrpc-methodology-01 Cases IP DNS HTTP P2P XMPP VPN Definitions Way forward - - Discussion of Glossary draft (10 min) https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01 - - Discussion of report draft (10 min) https://tools.ietf.org/html/draft-doria-hrpc-report-00 - - Discussion of 'The Internet is for End Users' draft (20 min) https://tools.ietf.org/html/draft-nottingham-for-the-users-02 - - Open discussion other drafts, papers, ideas (20 min) - - Charter update status (if necessary - 5 Min) - - Next steps (5 min) - - AOB - -- Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWNZiiAAoJEAi1oPJjbWjplWkH/Rk4MO6Ogq79/2nKCE3GZNxH /CPg9fcVNsezA+boxW3iYjoKbJ5OF4VNU0bULR+SJfSCc6MZ39s8P5EHpYXW4Mkq u1mRwvrm47dnAeWfbu0q6KQ6ohv7by9NHYMUjWUChU+3FmiDVFN53qzlgs/L9Dkg ldnbNhgTOEKSz7V3M7VGl2rQBr0iOQZk8SG3cz658e4T7t3GV1CZ6YK4khupY2JI 01dYKUGhwSB7I+CPilBLyLfsiTOW1PYVZeaq+7D8KMl9jO+MEopeFQGXswEuky/a vXYg+uEQbQelWy7XGTYO1ecwXwGwn4kg5aYoqvZk3xjSKymGLS03cWzYCItUU1o= =rUyH -----END PGP SIGNATURE-----