Subject: [hrpc] A review of draft-tenoever-hrpc-research-04.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 24 Jul 2016 18:29:09 +0200

TL;DR : good, and I think the RG last call (discussed in Berlin? I
don't find it in minutes) is a reasonable idea.

As you'll see, I have devoted most of my attention to section 5.

The biggest problem, IMHO, is the discussion of IP options in 5.2.3. I
know that we have already spent a lot of time on this (Andrew Sullivan
raised the point again a few weeks ago in "way forward
draft-tenoever-hrpc-research") but I still think the issue is
unsettled. The current text in -04 is on the verge of paranoid (by
giving the impression that the lack of multicast deployment was
deliberately engineered for evil purposes) and, more important, it
pushes "technical determinism" too far. The ability of people to
associate and interact does not depend on whether IPv4 multicast is
deployed or not. Basically, multicast was a bad idea from the
beginning (it works only when many people want to have access to the
same content AT THE SAME TIME, something which is now rare, except may
be for some sport events). Its absence does nothing to prevent people
from discussing on Web forums, mailing lists, or IRC channels.

I suggest to delete the text starting with "The second is the
selective..."

Another issue (which is not easy to solve) is the mention of Namecoin
in 5.2.4.1. The current text is technically correct but may give the
impression that Namecoin has only strengths, not weaknesses, and that
we endorse its use. I know it is not the case but I do not like the
current text, not because of what it says, but because of what it
omits. It claims "there is no technical auditing for name ownership
[in the DNS]" which is true but forgets to add that, in Namecoin,
there is a public ledger of changes, but based only on the possession
of a cryptographic key. If your machine is infected with malware, you
may lose your Namecoin name and there is no audit or recourse for
that (the ledger will only show "legitimate" changes.)

So, mentioning alternative techniques is a good idea, to illustrate a
point, but we must be careful to add that it is not a fair comparison.

Last important point, when rereading the evaluation of XMPP in 5.2.6,
I cannot help thinking it is technically correct but it may make
people consider that the XMPP authors were working for the NSA or the
FSB, trying very hard to break human rights in the protocol. May be
adding something that these evaluations are done on the basis of HR
influence, and that the engineers who built these protocols had many
other issues, and many trade-offs to consider (in the case of XMPP,
the use of the servers, which has a lot of consequences for HR, is
because user's machines are not reachable 100 % of the time.)

A few details (I can send pull requests if some of these points are
consensual):

5.2.5.1 : HSTS and certificate pinning are mentioned as solutions
against TLS stripping but not DANE (RFC 6698). Why?

5.2.11 : the end of the section is quite sudden. It regrets the lack
of a "de facto public space" but does not explain what it is (the
concept of "public space", where free speech and demonstrations are
possible, is not introduced anywhere). 

5.3.2.1.7 : "Yet, open standards are not explicitly defined
within the IETF" There is RFC 6852 but it is not a good reference
since it mentions IEEE, a very closed SDO (its standards are not even
freely available online). More a "governance circus" document than a
real definition of open standards.
   
Editorial :

5.2.5.2 : "The lack of a secure transport layer over HTTP connections"
Isn't it _under_ and not _over_? HTTP is layered over TLS.

5.2.9 : it should be updated with respect to the publication of RFC
7725. For instance, replace "would be named" with "is named".

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 29 Jul 2016 12:16:14 +0200

Hi Stephane,

Thanks for this! Reply inline:

> don't find it in minutes) is a reasonable idea.

I've updated the minutes to be more clear about the hum.

> I suggest to delete the text starting with "The second is the

I can live with this. And have adapted the text accordingly.
https://github.com/nllz/IRTF-HRPC/commit/a2a0064e7edfd1221e18311d11825225fee7aecb

> point, but we must be careful to add that it is not a fair comparison.

Sure, can you offer some text for this? We can also go for listing a few
short issues with Namecoin. Namecoin is only mentioned once, I do not
think it reads like a recommendation, but happy with considering adding
text.

PRs here pls:
https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md

> because user's machines are not reachable 100 % of the time.)

Sure! We don't want to lambast XMPP, but simply show how hard it is.
Would you like to offer text? I can also have a stab at it. Let me know
what you think.

> against TLS stripping but not DANE (RFC 6698). Why?

Let's add DANE, stupid to have not mentioned it. PR ?

> possible, is not introduced anywhere). 

We used to have much more text here, you can see it here:
https://tools.ietf.org/rfcdiff?url2=draft-tenoever-hrpc-research-03.txt
(page 37). I would be more than happy to bring (parts of) this text back:

DDoS although disruptive, and silencing at times, can also enable as
protest and speech. Or as Sauter {{Sauter}} argues: ‘though DDoS as a
tactic is still relatively novel, it fits within a centuries- long
tradition of breaking laws and disrupting business as usual to make a
political point. These actions aren’t simply disruption for disruption’s
sake. Rather they serve to help the activist or dissenter to direct the
attention of the public through the interpolation of difference into
routine.’ (30-31). An often heard argument against DDoS attacks is that
you cannot construe it as a means to exercise your right to freedom of
speech, when the means used effectively impede the right of the party on
the receiving end of the attack to exercise that same right. The problem
with this line of argumentation is that it conveniently ignores the fact
that online DDoS attacks are often one of the few effective ways for
activists to gain the attention of the media, the government or other
parties of interest. Simply putting up a website for a cause won’t
garner the same amount of attention as directly confronting the issue
via the website of the individual or organization at the heart of the
issue. The ability of activists to do so should be protected, especially
considering the fact that as Sauter (2014:4) explains: ‘Collectively, we
have allowed the construction of an entire public sphere, the Internet,
which by accidents of evolution and design, has none of the inherent
free speech guarantees we have come to expect. Dissenting voices are
pushed out of the paths of potential audiences, effectively removing
them from the public discourse. There is nowhere online for an activist
to stand with her friends and her sign. She might set up a dedicated
blog—which may or may not ever be read—but it is much harder for her to
stand collectively with others against a corporate giant in the online
space.’ Although the Internet is often compared to public space, it is
not. Rather the opposite. The Internet is almost entirely owned by
private entities. And the IETF plays a crucial role in developing this
privatized commercialized Internet.

> real definition of open standards.

We've been struggling with this but did not want to re-invent the wheel.
Happy to have guidance on where to look. I would have thought IETF would
have a stronger position on this documented somewhere, or at least the IAB.

> Isn't it _under_ and not _over_? HTTP is layered over TLS.

Changed, thanks.

> 7725. For instance, replace "would be named" with "is named".

Fixed, thanks!

Best,

Niels

> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>