On 09/13/2013 11:48 PM, Karl Malbrain wrote: > Sorry, I mis-read your "browser-vendor" concern section as "server" vendor. > > The browser should be able to cache the TLSA record on the local machine. > > Karl > > > > *From:* Karl Malbrain <[email protected]> > *To:* Leif Johansson <[email protected]> > *Cc:* "[email protected]" <[email protected]> > *Sent:* Friday, September 13, 2013 2:30 PM > *Subject:* Re: [perpass] proposed enhancement to TLS strong > authentication protocol > > Great news. Then all that is needed is a post connection exchange > comparison in the client between the server certificate used by TLS and > the one obtained from DANE. > > As to simple HTTP content servers, the use of the client authentication > interface is optional. If there is no interface handler installed, the > TLS package goes ahead and allows the connection. > > Note, for HTTP content servers that desire to authenticate client > connections as MITM free themselves, the in-page-rendering lookup is not > to an external source -- it's to the servers own account record where a > secure hash of the client certificate is stored during account creation. > > However for servers that act as client agents over some domain, the > server will track whether the authenticated user certificate "owns" the > account or is an unrecognized user, and preclude hacking the server by > guessing account names and passwords, etc.
If I understand correctly, you want to dynamically create client certificates and then check the client certificate information in combination with a user's login name and password. What happens if a user accesses a site from different devices/clients? What about sites where users don't log in at all? > > Yes, with DANE in place, this proposal is now entirely focused on > authentication by the server of clients. > > Karl > > > > *From:* Leif Johansson <[email protected]> > *To:* Karl Malbrain <[email protected]> > *Cc:* Randy Bush <[email protected]>; "[email protected]" <[email protected]> > *Sent:* Friday, September 13, 2013 2:05 PM > *Subject:* Re: [perpass] proposed enhancement to TLS strong > authentication protocol > > On 09/13/2013 10:40 PM, Karl Malbrain wrote: >> I'm not familiar with DANE. Is it operational? 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. >> > The DNS is quite operational and nothing stops anyone from publishing > TLSA records right this second. >> 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. > There have been credible arguments from browser vendors against any > scheme that involves > an in-page-rendering lookup to an external service that takes more than > a few milliseconds > because of the adverse effect on usability. > > Granted, TLS is about much more than the web but its still a major use-case. > > I suspect that any scheme that will have any chance of success must > involve pre-computing > some form of proof on the server-side that can be stapled onto the TLS > connection. > > Also you seem to focus on the client authenticating to the server which > quite frankly could make the > privacy story worse. >> >> Karl >> >> *From:* Randy Bush mailto:[email protected] >> *To:* Karl Malbrain mailto:[email protected] >> *Cc:* Leif Johansson 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 > > > > _______________________________________________ > 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 > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
