Quello che proponi è in realtà simile al normale https con il riutilizzo della sessione, cioè
- L'handshake iniziale richiede una crittografia asimmetrica per identificare il server e (in base al codice) per creare in modo sicuro la chiave per la crittografia simmetrica. La crittografia di trasporto viene quindi eseguita solo con la crittografia simmetrica.
- Le seguenti strette di mano riutilizzano solo la sessione esistente e serve solo la crittografia simmetrica.
Quindi ciò che proponi esiste, è stabilito e consiglio di usarlo.
Do you see any downside and security issues in this?
Non vedo alcun ovvio problema di sicurezza nella progettazione e nell'implementazione perché il design non è abbastanza specifico e non esiste ancora alcuna implementazione. Ma dal lato tecnico vedo diversi problemi:
- Non so come si implementa la crittografia, ma le librerie che implementano SSL / TLS sono già ottimizzate per la velocità (spesso usano l'accelerazione hardware). Riuscirai facilmente a superare questo problema con la tua implementazione?
- Il protocollo SSL / TLS è ampiamente utilizzato e pesantemente analizzato. Che ne dici del tuo design?
- Non ho mai capito perché chiunque sia interessato alle prestazioni utilizza comunque formati basati sul testo come JSON o XML. Se hai bisogno di prestazioni e bassi overhead, utilizza formati binari come protobuf o il vecchio ma stabilito Codifica ASN.1 .