On 12/2/15, Martin Rex <m...@sap.com> wrote: > Jacob Appelbaum wrote: >> >> I hope that we'll hide the SNI data by default and I understand that a >> discussion about encrypted SNI is currently scheduled for some point >> in the future. > > Hiding SNI data is completely silly security-wise, and any TLSv1.2 > backwards-compatible ClientHello must include a plaintext visible SNI. >
Not hiding SNI data is completely silly security wise. SNI data is used by attackers to perform denial of service attacks and to automate man-in-the-middle attacks. We have bare keys in TLS that may also be ephemeral - why would we want to reveal a selector to the network that we know is used for active attacks against the protocol? The question for a few people, myself included, is how we might protect the SNI data in an efficient manner. > So your client will have to know a-priori, out-of-band or be configured > to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello > with cleartext SNI. > I think that is false. One could easily use the "cleartext" SNI field and insert an encrypted value. A hash of the name would be a simple example but not a secure example, of course. To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less secure and in ways that will only become worse over time. We should remember that TLS 1.3, while not yet finished or deployed, is a future legacy protocol. We shouldn't burden the future with the failures of TLS 1.2 or any other SSL/TLS mistakes of the past. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
