>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

Reply via email to