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 <[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
