Re: [hrpc] reviews by Harry Halpin

[Niels ten Oever <[e-mail]>]

Thanks Harry,

Comments inline:


On 07/11/2016 09:39 PM, Harry Halpin wrote:
> 
> 
> 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."
> 

I've added this.

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

Thanks added.

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

Great work!

Cheers,

Niels


>> Thanks again for this great review.
>>
>> Best,
>>
>> Niels
>>
>>
>>
>>
>>
>>
> 
>