its not at all clear that the DNS service is "close" to the client - the last two studies indicate that DNS service is usually tied to a business relationship or a trust relationship. this will only increase with the lack of DNSSEC validation in the end system. as for prefetching, one -could- prefetch, I guess, but that would still be the normal query/response unless one were to redesign the DNS protocol…
/bill On 13September2013Friday, at 21:10, Yoav Nir wrote: > Hi > > I don't think that's necessary. DNS queries are usually done over UDP, so > there's no "connection", just an extra round-trip. And for the most part, the > DNS server is very close to the client, so those are not very expensive > round-trips. And you can make multiple requests in the same message. What > Warren is suggesting is that the DNS gratuitously return records you might > want soon, which would require the DNS to know a lot about the website, so I > don't think it's a worthwhile optimization. > > Yoav > > On Sep 14, 2013, at 2:35 AM, Karl Malbrain <[email protected]> wrote: > >> Warren, >> >> Since my proposal is now hooked to the widespread deloyment of DANE, and if >> DANE is being hindered by an ancient DNS protocol that requires multiple >> connections to secure a server's certificate and IP address, I'll have to >> include an item for DNS 2.0 that allows for multiple commands and multiple >> reponses in a simple cpio like data stream. >> >> Thanks for your help!! >> Karl Malbrain >> From: Warren Kumari <[email protected]> >> To: Karl Malbrain <[email protected]> >> Cc: Randy Bush <[email protected]>; Leif Johansson <[email protected]>; >> "[email protected]" <[email protected]>; Warren Kumari <[email protected]> >> Sent: Friday, September 13, 2013 4:03 PM >> Subject: Re: [perpass] proposed enhancement to TLS strong authentication >> protocol >> >> >> On Sep 13, 2013, at 6:19 PM, Karl Malbrain <[email protected]> wrote: >> >> > Doesn't DANE produce the server's certificate in the same connection that >> > DNS produces the servers IP address? >> >> Nope. >> >> > If not, that's an optimization that's needed. >> >> Would be nice, but, unfortunately DNS doesn't really allow you to return >> answers to questions that the client didn't ask… >> >> There are all sorts of sexy (and dangerous :-)) things that you could do if >> it did... >> E.g. - if a client asks for the A record for www.example.com they are >> presumably trying to reach my webserver and render a page -- which contains >> images from images.example.com and some ads from www.punchthemonkey.com, so >> I would like to be able to return: >> >> www.example.com 600 IN A 192.0.2.2 >> images.example.com 600 IN A 192.0.2.3 >> www.punchthemonkey.com 600 A 192.0.2.100. >> >> Or, even just returning MX responses in addition to A and AAA… >> >> W >> >> >> >> > >> > >> > Karl >> > From: Warren Kumari <[email protected]> >> > To: Karl Malbrain <[email protected]> >> > Cc: Randy Bush <[email protected]>; Leif Johansson <[email protected]>; >> > "[email protected]" <[email protected]>; Warren Kumari <[email protected]> >> > Sent: Friday, September 13, 2013 3:03 PM >> > Subject: Re: [perpass] proposed enhancement to TLS strong authentication >> > protocol >> > >> > >> > On Sep 13, 2013, at 4:40 PM, Karl Malbrain <[email protected]> wrote: >> > >> > > I'm not familiar with DANE. Is it operational? >> > >> > Yes, it is just not widely (enough) deployed. There are some browser >> > extensions and a browser (Bloodhound) that has support built in. There are >> > good tools to generate the DANE (TLSA) records, and e.g registro.br has a >> > simple one click "generate and publish a TLSA record" record for hosted >> > DNS customers. >> > >> > It is gaining traction in mail / SMTP, with support in Postfix. >> > >> > At the moment one of the main deployment hurdles is browser support (and >> > more DNSSEC deployment!). >> > Browsers (understandably) don't want to be waiting on TLSA records -- >> > latency is really important for browsers, and waiting for more DNS lookups >> > takes time. >> > >> > A few solutions have been discussed / suggested, such as only doing DANE >> > for self-signed certs, doing the TLSA lookup in parallel with the regular >> > lookup and making the normal connection, then aborting it (and replacing >> > the page with a notice) if DANE shows evidence of shennanigans and / or >> > caching TLSA records. >> > >> > W >> > >> > > Does it include changes to TLS to accept/compare the server's >> > > certificate obtained from DANE? If so, then that part of the proposal >> > > can be mooted in favor of DANE. >> > > >> > > Yes, it would be simpler to offload the certificate sourcing management >> > > to DNS. However, I'm proposing changes to be implemented entirely >> > > within TLS, that are transparent on the client side. Only the server >> > > side would require an additional interface to accept/reject client >> > > connections. >> > > >> > > Karl >> > > >> > > From: Randy Bush <[email protected]> >> > > To: Karl Malbrain <[email protected]> >> > > Cc: Leif Johansson <[email protected]> >> > > Sent: Friday, September 13, 2013 1:24 PM >> > > Subject: Re: [perpass] proposed enhancement to TLS strong authentication >> > > protocol >> > > >> > > [ off lst ] >> > > >> > > > I've dropped the idea of including both client and server public >> > > > certificates in the directory in favor of a server certificate only >> > > > repository with an additional TLS interface to authorize access by >> > > > clients. >> > > >> > > so why is this a win over dane? >> > > >> > > randy >> > > >> > > >> > > _______________________________________________ >> > > perpass mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/perpass >> > >> > -- >> > Hope is not a strategy. >> > -- Ben Treynor, Google >> > >> > >> > _______________________________________________ >> > perpass mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/perpass >> > >> > >> > _______________________________________________ >> > perpass mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/perpass >> >> -- >> With Feudalism, it's your Count that votes. >> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
