>I'm /soooo/ not a TLS person, but I think that this was discussed in >the TLS WG and didn't make it into the final spec -- it requires (at >least) an additional RTT. You do get SNI encryption with Zero-RTT, but >it's too later by then... >Some slideware: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf >The DNS SNI lookup could at least be done in parallel with the >"normal" DNS one (and, possibly returned in a >draft-wkumari-dnsop-multiple-responses answer :-))
To put it baldly, if it is a problem that SNI leaks, the solution is to fix SNI. This is not a solution, it is at most a band-aid that will deter a subset of unsophisticated snoops while adding useless complexity to https. For example, what are users supposed to do when the SNI DNS records and the SNI mapping in the servers inevitably get out of sync? "But fixing SNI is hard" isn't a good reason to do this. I understand that adding an extra round trip to the handshake would be a problem, but I am a long way from believing that's the only way to fix SNI. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
