<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">We need to move to more efficient protocols anyway, and this provides an ideal opportunity to implement two-cipher-suite protection, IMO.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">To enable zero-round-trip encrypted handshakes, the clients must retain information about the server from prior connections.  This should include a "long term key", such as regular DH-2048.  The first packet could be encrypted using a secret derived from the long-term DH-2048 server key and the local long-term DH-2048 key for that particular server.  This computation only needs to be done once, or until we begin to feel that our "long-term" keys are a little long in the tooth and need to be refreshed.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The first packet would not be forward-secure, meaning that if the long-term key were stolen/broken, these packets could be revealed.  The first packet should be a public "GET" request, and not passwords.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The first response from the server can be encrypted using an ephemeral ECDH 256-bit key.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The important step here is to insure that the ephemeral secret cannot be guessed unless _both_ the DH derived secret and the ECDH derived secret are cracked/stolen.  Simply computing SHA256(DH_secret || ECDH_secret) should be good enough.  All packets after the first one can be doubly-secured, and SFAIK, this does not present any new major burden on the protocols.  TLS 1.3 should probably do something like this to enable zero-round-trip handshakes.  The improved security would be a side-benefit :)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Bill</div></div></div>