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
