I'm sorry for the initial confusion mis-labeling client and server
authentication. Please see the most recent version of the draft where I tried
to straighten this out.
Yes, strong authentication of servers by clients is the step needed for MITM
resistance. The question raised in the draft about authentication by servers
of clients is that it should be occuring where strong authentication is desired
-- say by a bank, or government agency, to verify that the server is talking
directly to the client. It's for non-anonymous relationships where the server
holds some agency status and legal liability toward the user.
The draft is meant to outline a problem statement for a larger audience that
addresses not only protocol security improvements, but policy decisions.
________________________________
From: Paul Wouters <[email protected]>
To: Karl Malbrain <[email protected]>
Cc: Simon Josefsson <[email protected]>; perpass <[email protected]>; Stephen
Farrell <[email protected]>
Sent: Tuesday, September 24, 2013 2:16 PM
Subject: Re: [perpass] tld strong authentication deployment draft
On Tue, 24 Sep 2013, Karl Malbrain wrote:
> I've begun to propose an alternative to DNS/DANE, the PERSPECTIVES project
> from CMU, in version 01 of the problem statement:
> http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication.
>
> Have you considered what changes to the DNS system would address your
> concerns? I've proposed encrypted and authenticated connections
> in another thread.
strong authentication in clients will lead to less anonimity. What is
wrong with the model of the (anonymous) client authenticating the TLS
server against MITM, and than on that private channel, do client auth,
eg via basic auth?
I'm not sure what you are trying to solve by moving the client
authentication from the inner protected layer to the outer layer.
I'm also not sure what the draft is supposed to convey....
Paul
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
