As per current functionality, we cannot disable temp table encryption once we have enabled it. 

Other similar features like redo /undo log encryptions supports the  dynamic nature of variable during runtime.

As per discussion with Sergei over slack:

Mohit Joshi [2:28 PM]
if the system temp is un-encrypted, and we attempt to insert an ecnrypted table, should it fail?

Sergei Glushchenko [2:28 PM]
you mean `create temporary table .. encryption='y'` ?
i guess it should

Mohit Joshi [2:28 PM]
yup
ok..
Why are we just allowing temp table encryption=ON from client
IMO, it would be better from a user perspective that we should be able to disable something which we can enable
Suppose accidently a DBA set it to ON, he has no other way to disable it unless he restarts the server
Either make it a read only variable or make it completly dynamic

Sergei Glushchenko [2:32 PM]
enabling it doesn't put user at risk, while disabling it does... you may want to encrypt the server without restart...

Mohit Joshi [2:34 PM]
Enabling it will suddently start throwing errors for
CREATE TEMPORARY TABLE t1(a int);
because default value of innodb_encrypt_tables=OFF

Sergei Glushchenko [2:35 PM]
right... there are two similar settings - one to enable redo log encryption and another one to enable undo logs encryption, they are also dynamic and cannot be turned off
or can they be turned off?

Mohit Joshi [2:37 PM]
they can be turened off
for redo_log_encryption we can set either
ON->OFF->ON
MASTER_KEY->OFF->MASTER_KEY
KEYRING_KEY->OFF->KEYRING_KEY

Sergei Glushchenko [2:38 PM]
hmm... if user turn undo log encryption off, will undo logs be recreaded and unencrypted?

Mohit Joshi [2:38 PM]
the next page written would be un-encrypted
however what is already written will remain unchanged (edited)

Sergei Glushchenko [2:39 PM]
okay... I can make the -i-t-t-e variable behave the same (edited)