Hi, Thank you for the response.
I was not aware that the penetration rates of minor DNS records were low. I will read the I-D and the mailing list archive. OTOH, I think that the penetration rate being low might not be a killer for the proposal, since in the short term, SNI encryption can be an opportunistic feature, considering the fact that DNS packets will be sent in cleartext anyways. It might be possible to query for the A record and the bootstrap record simultaneously and activate SNI protection only if responses to both queries are obtained. 2017-07-19 6:03 GMT+02:00 Tom Ritter <t...@ritter.vg>: > 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 -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
