On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote: > > Hi folks, > > > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd > like > > the group's thoughts on. The goal is to make ESNI more robust and > eliminate > > a bunch of deployment risks. The PRs are linked below: > > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > > https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > > > The second recommends clients to send GREASE ESNI extensions when they do > > not have cached ESNIKeys available. This better meets the "Do not stick > > out" goal. The server behavior in the first PR gives us this for free. > > It seems to me that if server thinks it has ESNI enabled, but > the client does not get ESNI keys for it, then all handshakes fall > back to full handshake and session resumption will not work (as > the server is required to reject the resumption)? > It's possible I didn't word this correctly. If the client did not get ESNI keys for the server, the client is presumably offering a non-ESNI session, which has no resumption restrictions. The case we want to avoid is an ESNI session being resumed at anything other than esni_accept. That's to cut out the resumption case in {{verify-public-name}}. In particular, if we want to tolerate partial rollouts where some servers don't support ESNI at all while others don't at all, this scenario is a concern: 1. Server A does ESNI. Server B does not. 2. Client gets ESNIKeys from DNS and talks to server A. ESNI works out and all. It gets a session for origin-name. 3. Client connects again and this time load balances to server B. Or maybe server B is server A at a later time. Perhaps the ESNI implementation had a show-stopping bug and folks had to revert for now. It will send SNI=public-name, ESNI=origin-name, PSKs=ticket-for-origin-name. Since server B has no clue what's going on, it'll ignore the ESNI extension, and then process SNI + PSKs. This runs into the mess of cross-name resumption stuff. In particular, RFC 8446 says: Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session. The latter is a performance optimization: normally, there is no reason to expect that different servers covered by a single certificate would be able to accept each other's tickets; hence, attempting resumption in that case would waste a single-use ticket. If such an indication is provided (externally or by any other means), clients MAY resume with a different SNI value. It is not possible for the client to honor that first sentence because it is effectively offering two names at once, so it does not know which name the server will use to handle the ticket. This is kind of a headache. The ESNI bit in the session disambiguates by preventing the server from resuming under the SNI name. The semantics are: this session is associated with the ESNI name, not the SNI name. If you don't know what that means, or if you can't decrypt the ESNI name, please ignore it. Without this case (and GREASE---see remark), we could just say servers MUST NOT resume if they send esni_retry_request. > Also, randomly generating the ESNI key handle does stick out, as > normally the ESNI key is releatively static (DNS caching!) across whole > group of domains and servers. > This is true. I don't see a clear way around that one, short of taking the record_digest parameter out and requiring the server do a public-key trial-decrypt for each unexpired ESNI key. (Perhaps with key mismatch tolerance, it's no longer necessary for servers to be quite so paranoid about keeping all their old keys around, but the trial-decrypt still seems poor.) I think this is still worth doing, especially as it's basically free if you want to support rollbacks. (Making GREASE work and tolerating ESNI-clueless servers are very strongly related. GREASE requires that servers more-or-less ignore ESNI on key mismatch.) You also need to either observe multiple connections or know something about the server to do this. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
