If I remember correctly, the idea of enabling SNI encryption (and 0RTT) via DNS had been brought up very early on in the discussion. draft-nygren-service-bindings was the first (only? major?) concrete proposal.
In general, I think the feedback was "DNS gets filtered to only A/CNAME records so frequently that anything that relies on other DNS records isn't going to work an appreciable portion of the time". I'm disappointed by this also; but as we are also trying to deploy DNS privacy - mechanisms that rely on an easily surveilled, censored, or blocked mechanism to enable other sorts of privacy are concerning. -tom On 18 July 2017 at 22:42, Kazuho Oku <kazuho...@gmail.com> wrote: > Hi, > > I am happy to see us having discussions on how to protected SNI. I am > also happy to see that draft-huitema-tls-sni-encryption [1] proposes > actual methods that we might want to use, and that the I-D discusses > about various attack vectors that we need to be aware of. > > On the other hand, as stated on the mailing list an on the mic, I am > not super happy with the fact that the proposed methods have a > negative impact on connection establishment time. > > So here goes my straw-man proposal, as an Internet Draft: > https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/. > > In essence, the draft proposes of sending information (e.g., > semi-static (EC)DH key) to bootstrap encryption in ClientHello as a > DNS record. Clients will use the obtained (EC)DH key to encrypt SNI. > > Since DNS queries can run in parallel, there would be no negative > performance impact, as long as DNS responses can be obtained in a > single RTT. > > The draft mainly discusses about sending a signed bootstrap > information together with the certificate chain, since doing so is not > only more secure but opens up other possibilities in the future (such > as 0-RTT full handshake). However, since transmitting a bootstrap > record with digital signature and identity is unlikely to fit in a > single packet (and therefore will have negative performance impact > until DNS over TLS or QUIC becomes popular), the draft also discusses > the possibility of sending the EC(DH) key unsigned in the "Things to > Consider" section. > > I would appreciate it if you could give me comments / suggestions on > the proposed approach. Thank you in advance. > > [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ > > > ---------- Forwarded message ---------- > From: <internet-dra...@ietf.org> > Date: 2017-07-19 5:38 GMT+02:00 > Subject: New Version Notification for draft-kazuho-protected-sni-00.txt > To: Kazuho Oku <kazuho...@gmail.com> > > > > A new version of I-D, draft-kazuho-protected-sni-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. > > Name: draft-kazuho-protected-sni > Revision: 00 > Title: TLS Extensions for Protecting SNI > Document date: 2017-07-19 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt > Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/ > Htmlized: https://tools.ietf.org/html/draft-kazuho-protected-sni-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00 > > > Abstract: > This memo introduces TLS extensions and a DNS Resource Record Type > that can be used to protect attackers from obtaining the value of the > Server Name Indication extension being transmitted over a Transport > Layer Security (TLS) version 1.3 handshake. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -- > Kazuho Oku > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
