Re: [hrpc] reviews by Harry Halpin

[Harry Halpin <[e-mail]>]

On 07/06/2016 08:09 PM, Niels ten Oever wrote:
> Hi Harry, 

These are all minor optional notes, and I'm happy to see the draft go
forward without them.
> 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.

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

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

OK

>
>> ·      @@: 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.


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/
>> ·      @@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/ )



"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. 
>
>
>> @@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?


"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/
>
> Thanks again for this great review.
>
> Best,
>
> Niels
>
>
>
>
>
>