Subject: Re: [hrpc] reviews by Harry Halpin

From: Niels ten Oever <[email-masked]>
Date: Wed, 6 Jul 2016 20:09:21 +0200

Hi Harry,

Corinne and I have went through your comments, for which I would like to
thank you again. Most issues have been addressed in the draft that is
about to be published (for which you can find the md here:
https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
, I think it made the draft much better, thanks a lot. There are a few
things unresovled though:

> ·      Federation  The possibility of connecting autonomous systems
> into single distributed system. @@: Distibuted system has a
> well-defined meaning in computer science. I'd say 'decentralized'
> here and note that 'autonomous and possibly centralized'

We have went with this solution because there is a lot of contention
about what 'decentralized' is. Therefore we said that everything that is
federated is by defintion distributed.
Are you proposing:
·      Federation  The possibility of connecting autonomous systems into
single autonomous and possibly centralized system.?
Am not sure if it would be much clearer, I also do think that it is in
line with the provided definition of distributed system.

> ·      Methodology @@: While interesting from an academic
> perspective, it seems like this should be in an appendix or towards
> the end and referenced

I think we'll keep this here, because it is an IRTF document (focusing
on research). If we want to guidelines to be normative or relevant for
the IETF we will need to bring it up there.

> ·      @@: Noting Moxie's SSLstrip makes this capability available to
> almost anyone, as its is likely a *design flaw* that the identifier
> of the encrypted version (https://) of a resource is different than
> an unencrypted one (http://), although it is likely a design flaw
> that is is too late to fix. Only with HSTS and certificate pinning
> (failed IETF draft for it as "Tack") can this attack really be dealt
> with.

I do recognize this problem, but am not sure whether adding this hear
will add much to the purpose of the draft, but curious to hear opinions
from others on this.

> ·      @@IETF does not in general have much
> work in standardizing P2P protocols. Should it? Should this be
> included if the protocol was designed outside the IEF?

There is increasingly work on P2P in IETF, am not sure why we should
exclude this (RFC5128, RFC5694, but also:
https://datatracker.ietf.org/wg/p2psip/charter/ )

> @@You should not patents, and the destrutive role patents have had in
> holding back cryptography, in particular elliptic curves or even
> Schnorr signatures, and how the IETF "Note Well" and W3C
> "Royalty-Free licensing Patent policy" given a definition of open
> stanardization in terms of intellectual property.

Could you provide us some text for this?

Thanks again for this great review.

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Jul 2016 11:26:54 +0200

Hi Niels,

> Could you provide us some text for this?

Much as I agree with Harry's concerns about patents, I'm a little
nervous that your document will become the kitchen sink to discuss all
evils.  That to me is a separate document.  One could in fact write a
book – dare I say manifesto – on that subject alone...

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 7 Jul 2016 11:45:04 +0200

Hi Elliot,

> book – dare I say manifesto – on that subject alone...

I recognize your concern, and it is by no means my intention to make
this draft a manifesto for everything that is right/wrong in protocols,
but rather a way to make impacts on peoples rights more visible and give
people a structure and document their decisions.

As Scott made it clear, we should make it very clear why we think this
is the case, preferably based on other research, examples and RFCs to
show that the relations between rights and protocol/practice are not
made intuitively, but rather building on best practices and real world
situations.

Best,

Niels

---

From: Harry Halpin <[email-masked]>
Date: Mon, 11 Jul 2016 17:34:19 +0200

> people a structure and document their decisions.

Yes, however it's important to distinguish 'open standards', as defined
by a multi-stakeholder process and some reasonable way of dealing with
patents, versus closed standards done by closed committees that, despite
using the term 'standard', may involve intellectual property that harms
implementation by vendors, including but not limited to open-source.
Thus, I think as an important part of the appeal of the open internet
(and it's perhaps the primary reason why the W3C has member companies)
and in particular given the well-known problems in cryptography
resulting from patents, it deserves to be mentioned.

---

From: Harry Halpin <[email-masked]>
Date: Mon, 11 Jul 2016 21:39:19 +0200

> Hi Harry, 

These are all minor optional notes, and I'm happy to see the draft go
forward without them.
> line with the provided definition of distributed system.

That edit would be a bit backwards.

The simplest edit would be "The possibility of connecting autonomous
systems into single system"

Since the term 'decentralization' can be difficult (unlike
'distributed', it isn't well defined in computer science), the more
complex edit would be "The possibility of connecting autonomous and
possibly centralized systems into single system without a central
authority."

> the IETF we will need to bring it up there.

OK

> will add much to the purpose of the draft, but curious to hear opinions

If you are going to discuss the use of TLS, this should probably be
mentioned. In general, bolting on privacy and crypto after a protocol
like HTTP is already deployed is hard. I would note that "HTTP upgrading
to HTTPS is also vulnerable to having an attacker remove the "S" in any
links to HTTPS URIs from a web-page transferred in cleartext over HTTP,
an attack called "SSL Stripping" [1]. Thus, for high security use of
HTTPS IETF standards such as HSTS [2] and certificate pinning should be
used [3]."

[1] https://moxie.org/software/sslstrip/
[2] https://datatracker.ietf.org/doc/rfc6797/
[3] https://datatracker.ietf.org/doc/rfc7469/
> https://datatracker.ietf.org/wg/p2psip/charter/ )

"Defined" here was the word that confused me. SIP is just a
multimedia-over-IP protocol (used mostly for voice in my experience),
and p2psip is just a way of doing SIP with a p2p discovery service, i.e.
a DHT - unlike, say, most uses of WebRTC. Thus, P2PSIP is more of a
corner-case than a fundamental standard for P2P.  I am not aware of more
generic and popular deployed P2P frameworks (thinking Bitcoin, Tor,
BitTorrent, even FreeNet) that were standardized at the IETF. So, I'd
rephrase the sentence as

"Peer-to-Peer (P2P) is a network architecture in which all the
participant nodes can be responsible for the storage and dissemination
of information from any other node (as defined in {{RFC7574}}, an IETF
standard that uses a P2P architeture)."

My general take on P2P is summed up by Phil Agre quote: "Architecture is
politics, but it is not a substitute for politics" in his article "p2p
and the promise of internet equality." In fact, due to sybil attacks
that are quite easy to mount today,  I tend to discourage their use in
practical applications by at-risk human rights defenders. 
> Could you provide us some text for this?

"Do you normatively reference another standard that is not available
without cost? Are you aware of any patents that would prevent your
standard from being fully implemented?"

..

"All standards that need to be normatively implemented should be freely
available and with reasonable protection for patent infringement claims,
so it can also be implemented in open source or free software. Patents
have often held back open standardization or been used against those
deploying open stadards, particularly in the domain of cryptography [1].
Patents in open standards or in normative references to other standards
should have a patent disclosure [2], royalty-free licensing [3], or some
other form of reasonable protection. Reasonable patent protection should
includes but is not limited to cryptographic primitives.

[1]
http://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/
[2] https://www.ietf.org/about/note-well.html
[3] https://www.w3.org/Consortium/Patent-Policy-20040205/

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 12 Jul 2016 11:54:12 +0200

Thanks Harry,

Comments inline:

> possibly centralized systems into single system without a central

I've added this.

> standard that uses a P2P architeture)."

Thanks added.

> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/

Thanks added.

Great work!

Cheers,

Niels