[foaf-protocols] consent to encrypt the FOAF de-referencing act, in FOAF+SSL
henry.story at bblfish.net
Tue Dec 7 20:52:35 CET 2010
On 7 Dec 2010, at 18:06, peter williams wrote:
Thanks for the link.
> 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.
KEK = key encryption key (KEK) ?
Sounds very interesting. Thanks for the pointer...
> 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.
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
Social Web Architect
More information about the foaf-protocols