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.
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]
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
