[foaf-protocols] psk with dh ciphersuites, variant for foaf+ssl

[Peter Williams]

The PSK variant of SSL http://tools.ietf.org/html/rfc4279#section-5.1 also addresses foaf+ssl issues. Specifically, by the server limiting the right PSK ciphersuite one can know that there is perfect forward secrecy in the foaf+ssl identity assertion (PFS has a property that compromise of one session crypto material has limited impacts on historical sets of derived keying material). One might note that its uses the principle of client-side ephemeral asymmetric keying (which mints a public key pair on the fly, for each full handshake sending a cert). Combined with a self-signed cert (with webid) as the identifier hint from client to server, choosing the ciphersuite  for the job at hand + the elimination of PKI trust (formally) .... PSK-SSL might serve foaf+ssl well.

But there is more to the PSK ciphersuites than the trust model, the keying manageability, the identifier format, and the security services. It comes down to Dan Simons original concept (when designing PCT - a variant of SSL v2). There was a desire to encrypt a stream once, store it in a file, and be able to send it multiple time in (strongly) pre-encrypted form through an SSL tunnel (without incurring tunnel re-encryption overheads, or using low-end American ciphers that could be spied upon easily). Through record-layer payload insertion, a browser (plugin, such as a payment module) could insert onto an existing SSL record layer a custom "SSL protocol/payload" - that was flagged as being and treated  as being pre-encrypted (and thus pre-data origin authenticated, by PSK). The cipherstext could be replayed furthermore, should stateless web and back-button happy browsers interfere with reliable, indempotent message delivery.

The main focus was signed form posting, as I recall from the public part of the disclosures. But, one can look at the opportunity the other way around too. One way to avoid signing graphs (which is not a solved problem), would be to pre-encrypt the representation of cached copies in the data repository using a PSK, where the foaf+ssl after doing identity assertions using the SSL handshake protocol delivers  their pre-encrypted (and thus data origin authenticated) sub-stream to http clients. This (SSL) protocol type would be the only other data protocol/payload  type allowed on an foaf+ssl-keyed or key-derived record layer.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091129/848f8f21/attachment.html