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]<mailto:[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]<mailto:[email protected]>> To: Karl Malbrain <[email protected]<mailto:[email protected]>> Cc: Randy Bush <[email protected]<mailto:[email protected]>>; Leif Johansson <[email protected]<mailto:[email protected]>>; "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>; Warren Kumari <[email protected]<mailto:[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]<mailto:[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<http://www.example.com> they are presumably trying to reach my webserver and render a page -- which contains images from images.example.com<http://images.example.com> and some ads from www.punchthemonkey.com<http://www.punchthemonkey.com>, so I would like to be able to return: www.example.com<http://www.example.com> 600 IN A 192.0.2.2 images.example.com<http://images.example.com> 600 IN A 192.0.2.3 www.punchthemonkey.com<http://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]<mailto:[email protected]>> > To: Karl Malbrain <[email protected]<mailto:[email protected]>> > Cc: Randy Bush <[email protected]<mailto:[email protected]>>; Leif Johansson > <[email protected]<mailto:[email protected]>>; > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>; Warren Kumari > <[email protected]<mailto:[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]<mailto:[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<http://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]<mailto:[email protected]>> > > To: Karl Malbrain <[email protected]<mailto:[email protected]>> > > Cc: Leif Johansson <[email protected]<mailto:[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]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/perpass > > -- > Hope is not a strategy. > -- Ben Treynor, Google > > > _______________________________________________ > perpass mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/perpass > > > _______________________________________________ > perpass mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/perpass -- With Feudalism, it's your Count that votes. _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
