Re: [TLS] Industry Concerns about TLS 1.3

[Ryan Carboni <[e-mail]>]

>
> The impact on supervision will be particularly severe.  Financial institutions are required by law to store communications of certain employees (including broker/dealers) in a form that ensures that they can be retrieved and read in case an investigation into improper behavior is initiated.  The regulations which require retention of supervised employee communications initially focused on physical and electronic mail, but now extend to many other forms of communication including instant message, social media, and collaboration applications.  All of these communications channels are protected using TLS.
>
>
In the past ten years, we have seen botnets, root kit trojans, root kit
DRM, NSA TAO implants, OpenSSL heartbleed, heartbleed-style attack against
Cisco routers, cold boot attacks against expanded subkeys from a linear key
schedule, etc, etc...

I do not think encryption to be an obstacle of any kind.

Just use a forward proxy and move encryption from the browser to a
dedicated appliance? https://github.com/joshdick/miniProxy <- just from
Googling "php proxy"

And I think the only way to protect against heartbleed is require private
keys larger than than the MTU. But private keys are kind of pointless
nowadays when google has their private keys on thousands of machines around
the world.

Although DH depends on both parties generating a high entropy secret.
Personally I think the observation by an NTRU employee on NTRU-KE is better
than DH: https://github.com/NTRUOpenSourceProject/NTRUEncrypt/issues/7 "We
probably won't implement this exact idea -- this is basically each side
encrypts a secret, sends to the other, and puts the result through a KDF,
but with the slightly artificial choice that the encrypted secret is also
the private key and the KDF involves multiplication. Currently you can get
the properties that NTRU-KE gives (i.e. that both sides contribute secret
randomness) simply by using standard NTRU in each direction to send two
secrets and it's not clear what advantages NTRU-KE would have over that.
There may be room for a custom key exchange scheme in the future, but we'd
want to make sure it had advantages over the obvious way of doing it.


This shouldn't be a problem, but in the internet of things, DH is actually
less secure than normal public key exchange. Servers are more likely to
have entropy than embedded devices.

Ultimately, the world is insane.