- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 18 Feb 2011 20:42:00 +0100
- To: Peter Williams <home_pw@msn.com>
- Cc: Peter Saint-Andre <stpeter@stpeter.im>, "nathan@webr3.org" <nathan@webr3.org>, WebID Incubator Group WG <public-xg-webid@w3.org>
On 18 Feb 2011, at 20:07, Peter Williams wrote: > Look up winsock, in windows world. Ah yes: http://en.wikipedia.org/wiki/Winsock [[ In computing, the Windows Sockets API (WSA), which was later shortened to Winsock, is a technical specification that defines how Windows network software should access network services, especiallyTCP/IP. ]] [[ Early Microsoft operating systems, both MS-DOS and Microsoft Windows, offered limited networking capability, chiefly based on NetBIOS. In particular, Microsoft did not offer support for the TCP/IP protocol stack at that time. A number of university groups and commercial vendors, including the PC/IP group at MIT, FTP Software, Sun Microsystems,Ungermann-Bass, and Excelan, introduced TCP/IP products for MS-DOS, often as part of a hardware/software bundle. ]] Ah so winsocks is not a microsoft invention? Well, don't trust wikipedia. It has win in the name. > On unix, look up socket. Oh yes, I use those all the time. http://download.oracle.com/javase/1.4.2/docs/api/javax/net/ssl/SSLSocket.html > For ssl and sockets, perhaps read the patent. yes, sockets are real cool, patent pending I am sure. > It's focussed on corporate firewalls. Yes. Read the patent, and know that many browsers originally had no tcp, thus connectivity required the proxy bridge in support. Browsers pretending to talk end end (while not) is a long story. Incredible story indeed! I recommend this patent pending thesis by some Fielding "Architectural Styles and the Design of Network-based Software Architectures" http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Especially the "Client-Cache-Stateless-Server" http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_4 The cache is a acting like a trusted proxy. You're onto something. > As wirespeeds hit 100gbps in the next 12m, I suspect the same story will roll out to the ISP (or modem dsams), so it applies to home users too. The web is a malevolent place (if you listen to the billion dollar companies selling security and trust). But I hear some of those entrepreneurs are very generous with their money. Robin Hood style: take from the fools, give to the poor. > > Also got to chat to the semantic/pgp/intel guys who are deploying the brick-a-pc world. All core i3 chipsets come with " trustworthiness" built in: should reputation go below x, when pc pings internet (isp?) for authority to stay unbricked,authority is witheld. Pc becomes useless (as does the stored data locked by it's Tpm chip). SMS and radio offer alternative kill switches. Wow! > Military assurance through and through. Be careful what you wish for. Well I think the computer industry could do with more such security. Just imagine who that would get people to think carefully about what they download. And for those who are not careful its a business opportunity for us. > > > On Feb 18, 2011, at 10:23 AM, Henry Story <henry.story@bblfish.net> wrote > >> >> On 18 Feb 2011, at 18:59, Peter Williams wrote: >> >>> Got to study modern tls sockets this week, in which winsock interceptors "add security semantics" to the channel (tls or dtls). >> >> Is there documentation on this? Or is this a windows only technology? >> >>> Designed for corporate markets, the browser is largely sidelined. The browser pretends to the user that she is talking to site x (though she is not.) Data flows are inspected at the inspection point, malware signatures evaluated at wire speed of 40gbps, and tls sidechannels (custom record layer protocols) used to exchange sideband signals between inspector and trusted desktop security agent - since the browser is treated as an untrustworthy system component, in general (being designed for webiness). >> >> This sounds like it is made for internal company firewalls, right? It also sounds great for spies of all sorts... Untrustworthy browsers indeed. >> >>> Of course the goal here is in part to redefine webiness to define a relevant browser assurance, that helps redefine the moribund trust research space (full with reputation, trust, threat, dossier based conceptions based on metric theory). >> >> We are also going to redefine the market for ultra high value extensible solutions for security research with Military grade encryption and spy level intertrust. When we are finished the interoperable ultra future secure web trust solution will change the way we think and the way we live, nothing less. For this we are going to start by working on some hard level crypto logic, with Department of defence budgets, to break through this NASA type rocket problem, and land us on the crypto moon. Superman, beware. >> >>> Webid had to define a new relevant space that originates new secure communication modes at (huge) scale, rather than just reimplement old protocols with new syntaxes. >> >> We are not looking to do small simple things here of course: we leave that to the simpletons. Nothing less than massive re-engineering of the browser is needed to get us to the secure future and the new operating system. But we should not leave it at that! The protocols worked on at the web level are way to simple to deal with this solution that we are about to invent, and demand a high octane reengineered solution for the colossal scale crypto issues that the future is going to deal with. Nothing less. This is the place to be. This is the place to watch out for. Put your signs up here. The market must begin. And how much are we going to sell that solution for? In these tight budget days we have to tighten our belts. 100 billion dollars was the initial price. But no we have a patent pending solution to reduce the cost for you. Yes, for you today we are going to make it not even for 10 billion. Who says more? Who! 10 billion for the Egyptian dictator to the right? Great! Who says more? Deal done. That's how we must do research. Dollar value, in the billions. It's hard talk here. >> >>> My gut goes with connectionless https, with gdoi style key management (in signed canonical json or x509 certs, I could care not a jot which - unless legacy browsers are to be addressed). >> >> My gut is with you on this. It's a tough quick reaction, shoot from the hip world. One second too late and your amigoes with the worms. It's a man's world here, those with guts and shooting skills win out. JSON or X509, are the desperadoes on the road above. We got to keep our eyes peeled on those shadowy legacy agents. They'll shoot you in the back if you don't watch out. >> >> >>> On Feb 18, 2011, at 9:00 AM, Henry Story <henry.story@bblfish.net> wrote: >>> >>>> >>>> On 18 Feb 2011, at 17:32, Peter Saint-Andre wrote: >>>> >>>>> On 2/18/11 9:29 AM, Henry Story wrote: >>>>> >>>>>> For me it's easier to put all documents behind https, have users >>>>>> publish the public key as specified below for WebID authentication >>>>>> and do access control: only allow authorised users to retrieve the >>>>>> document. There you get on the fly encryption of any content you >>>>>> send. >>>>> >>>>> To clarify requirements, many of those who are interested in this work >>>>> at the IETF want to make it possible for browser-based clients to do >>>>> things like encrypted instant messaging or voice and video signalling. >>>> >>>> Though there again, I suppose the browser could just connect to the server >>>> over https and send the content that way... That should be able to cover a >>>> lot of use cases. I suppose one could also use DTLS for voice over ip. >>>> >>>>> So perhaps the scope is a bit broader than WebID >>>> >>>> different use cases probably... >>>> >>>> It is just interesting to see how far one can push those down to the TLS level. Every time one can do that one reduces the need for a special encryption and authentication syntax for the content sent. The end user can just receive the content and parse it cleanly. >>>> >>>>> (I confess to not having followed WebID closely). >>>> >>>> In the current context one could think of WebID as just being https that works. A client can connect securely and identify himself to any server. The rest is then taken care of by TLS. >>>> >>>> But signatures and encryption at the document level comes up all the time. >>>> >>>> Btw. in the semweb land there is the work on "Signing RDF Graphs" >>>> by Jeremy Caroll >>>> >>>> http://www.hpl.hp.com/techreports/2003/HPL-2003-142.html >>>> >>>> Henry >>>> >>>>> >>>>> Peter >>>>> >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/
Received on Friday, 18 February 2011 19:42:45 UTC