4 ms·

Looking at the setup code here, this looks a lot like SSL reinvented over Kafka (instead of over TCP), which is not a bad thing, just the mechanism feels a lot

by gopalv 5y ago

Looking at the setup code here, this looks a lot like SSL reinvented over Kafka (instead of over TCP), which is not a bad thing, just the mechanism feels a lot like you've automated a tcpdump into the protocol by making the handshake packets persisted in the stream + committed to disks. This somewhat makes sense if you're going to buy Kafka from a cloud provider without the ability to trust them, but the trust here is not very useful beyond securing transport trust. E2e for Kafka usually shows up as a mechanism to encrypt each item differently, because that has a bigger use-case in it. Kafka being an immutable log, there is no way to go back and delete data for a customer who asks for a data deletion or legally mandated GDPR data removals. Being able to shred the keys is very useful if you have a destination or source attribute based keys - instead of purging data out of the kafka log you can throw away the key.

bdamm 5y ago
Perfect Forward Secrecy is pretty standard in TLS handshakes these days, so the persistence of messages should not be an issue. This pattern of burying TLS inside of application payloads is popping up all over the place. People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports.
- mattgreg 5y ago
  "People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports." Exactly right. Application layer trust, with the transport and security layers abstracted away. This is important, since app developers typically can't control the transports from end to end, or at scale.
mwadhwa 5y ago
Great observations! Data removal from Kafka for GDPR compliance is trivial in this setting. You just purge your keys. There are also key rotation and revocation protocols that are part of Ockam and we're making them simple to use from our libraries. The underlying cryptography in Ockam SecureChannels comes from the Noise Protocol Framework (created by one of the authors of Signal Messenger's protocols). The Noise Framework protocols have many published security proofs and is gaining adoption in multiple secure systems. We are proposing an alternative to SSL/TLS but this alternative is well proven/understood in terms of it security guarantees.

by gopalv 5y ago

bdamm 5y ago

Perfect Forward Secrecy is pretty standard in TLS handshakes these days, so the persistence of messages should not be an issue. This pattern of burying TLS inside of application payloads is popping up all over the place. People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports.

mattgreg 5y ago
"People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports." Exactly right. Application layer trust, with the transport and security layers abstracted away. This is important, since app developers typically can't control the transports from end to end, or at scale.

mwadhwa 5y ago

Great observations! Data removal from Kafka for GDPR compliance is trivial in this setting. You just purge your keys. There are also key rotation and revocation protocols that are part of Ockam and we're making them simple to use from our libraries. The underlying cryptography in Ockam SecureChannels comes from the Noise Protocol Framework (created by one of the authors of Signal Messenger's protocols). The Noise Framework protocols have many published security proofs and is gaining adoption in multiple secure systems. We are proposing an alternative to SSL/TLS but this alternative is well proven/understood in terms of it security guarantees.