[Cryptography] At what point should people not use TLS?

[Trevor Perrin]

On Tue, Apr 12, 2016 at 2:35 PM, Jerry Leichter <leichter at lrw.com> wrote:
>> Abbreviated handshake
>> ---------------------------------
>> TLS session resumption is based on caching the original session's
>> master secret.  So forward secrecy and resistance to "key-compromise
>> impersonation" is reduced: if the cached master secret is stolen from
>> the client or server, older sessions can be decrypted and the server
>> can be impersonated.
> I haven't looked at the whole protocol so may well be missing something essential, but the forward secrecy part seems easy to fix:  Rather than caching the original session's master secret, cache its one-way hash.

That's better, though as you note it only addresses "forward secrecy"
- not "key-compromise impersonation" of the server.

Also note that clients perform lots of resumptions based on a single
initial session, so keeping the state updates synchronized between
clients and servers could get tricky:
 - What if the client starts a bunch of resumption sessions in parallel?
 - What if the client's zero-RTT message, or the server's response, get lost?
 - What if the server replicates the resumption cache to different machines?

Encrypting the zero-RTT data to a cached public key is a different
design choice, which could have advantages:
 - no secrets stored on client
 - no state synchronization needed
 - ability for clients to fetch the zero-RTT public information
out-of-band, e.g. from a directory service, or pre-configured.

Noise makes this sort of public-key based zero-RTT encryption easy,
either encrypting to the server's long-term public key (simpler
implementation), or encrypting to a shorter-term "semi-ephemeral"
public key, if you'd like shorter forward-secrecy windows.

Trevor