Re: [TLS] 0RTT?

> The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh
> key): data encrypted as usual under the old ciphersuite follows. 

I guess I don’t understand what this means. Is the new application data encrypted
under (a) the old MS? (b) a new MS derived from PMS_interim (and the old randoms)? 

> 
> On receiving this a server looks up the anti-replay nonce and checks
> it is fresh. To make this easier we include UTC time since the epoch (
> midnight of 1 January 1970) and mandate some degree of synchronization
> and a window. To avoid tagging with clock drift we truncate some low
> order bits after adding a random small offset.
> 
> If the nonce is not previously seem the server can send Application
> Data as normal.
> 
> We now introduce a new handshake type: Rekey Finish, containing a new
> ticket and server key. CCS follows afterwards. These are sent
> encrypted.
> 
> The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)).
> 
> The big limitation is ticket keys are going to need rotation. This
> also doesn't address the desire to put extra data in DNS to give some
> degree of forward secrecy, but I don't think you can change DNS that
> quickly without some problems.
> 
> Furthermore, if we want rekeys without renegotiation, we can reuse
> Rekey Finish and add a Rekey Initiate handshake type that will send
> the client key.
> 
> Open questions: how secure is this? We certainly need to hash the
> anti-replay nonce into the keys: is that all we need? (Not if we want
> to avoid attackers manipulating which method we use) Does noisy
> truncation work to prevent fingerprinting while reducing storage
> requirements?
> 
> Sincerely,
> Watson Ladd
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls