Most https protected channels are to servers with some sort of agency on behalf
of the client. My bank account connection for example allows anyone in the
universe to try to hack into my account by guessing the account name and
password. If this connection were authenticated through my public certificate
to my private key I, and the bank, wouldn't have to worry anywhere near as much
as I do now due to the extra layer of security being offered.
Portability of the private key to a new platform can be a concern to be
addressed independently. In my case I only access my account from a single
computer. Theft of the computing device would be a threat vector.
There is also the question of due dilligence on behalf of server operators that
information being transmitted over the connection cannot be eavedropped by MITM
style intrusion to third parties.
Karl
________________________________
From: Randy Bush <[email protected]>
To: Karl Malbrain <[email protected]>
Cc: Leif Johansson <[email protected]>; "[email protected]" <[email protected]>
Sent: Friday, September 13, 2013 2:52 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.
yes, that is what dane clients do
> Yes, with DANE in place, this proposal is now entirely focused on
> authentication by the server of clients.
though occasionally useful, it is not necessarily a good idea in the
privacy context
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
