[foaf-protocols] consent to encrypt the FOAF de-referencing act, in FOAF+SSL

peter williams home_pw at msn.com
Tue Dec 7 18:06:44 CET 2010



In the proposal cited above, derivatives of ssl3's master key are used for
data encipherment before the server has EVEN SIGNALLED consent to the KEK(s)
being used for the wrapping/unwrapping  of traffic encryption keys. By
design in SSL3, only receipt of server's handshake authorizes use of the
client's cryptosystem (embodying the notion of pairwise/mutual agreement,
and providing the basis for export controls monitored by "trusted servers").


This rationale for this "innovation" is stated as being one of reducing the
latency of getting pages (such as a foaf file) from a server - simply
because the URI-dereferencing request arrives earlier in the server's
pipeline processor. 


If I look at this through an alternative lens (and assume cloud firms are
doing deals with crypto authorities in order to obtain government cloud
contracts), I suspect it more to do with setting a new precedent: that the
derivatives of master keys (KEKs, more technically) **no longer** require
consent of both parties to be "used." Such a precedent would (incidentally)
create that basis that the same KEK can be given in parallel to third
parties (without prior consent *OR* knowledge of the other server).


This is the attack on SSL3. The first attempt was to have IETF ban SSL3 per
se (on the basis that the use of MD5 compromises SSL, despite MD5
specifically being supported by NSA's own SHA1 **specifically* to addresses
the lack of strength in MD5 compression function that was known about even
15 years ago.). The latter point is glossed over, of course.


SSL3 clearly *is* holding backing wider adoption of certain TLS features,
including more modern pipelining in hardware doing fastTCP or FCIP over
TCP/TLS tunnels. But, SSL3 is also holding a line in the sand on
cryptopolitics - that is not held by TLS. 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101207/dad0a304/attachment.htm 

More information about the foaf-protocols mailing list