Hi, We seem to be designing this protocol one mail at a time. Could I ask that we stop doing that and that Karl and whoever else is minded submit an internet-draft specifying the protocol so that it can be more easily reviewed.
Thanks, Stephen. PS: Karl, if you need help with the mechanics just ask me offlist. On 09/12/2013 05:24 PM, Karl Malbrain wrote: > The assumed attack profile is a MITM insertion into a connection stream > between server and client whereby the attacker gains complete unencrypted > access to all traffic over the connection, not just meta data. > > TLS already has a built-in concept of "strong authentication" between server > and client to defeat this attack. It requires that the TLS server pre-obtain > by some secondary channel the public key of the user. This proposal > eliminates that requirement by making the user's public keys public knowledge. > > Karl > > From: Jon Callas [mailto:[email protected]] > Sent: Thursday, September 12, 2013 06:21 > To: Karl Malbrain > Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; [email protected] > Subject: Re: [perpass] proposed enhancement to TLS strong authentication > protocol > > > On Sep 11, 2013, at 11:56 AM, Karl Malbrain > <[email protected]<mailto:[email protected]>> wrote: > > > The goal of the proposal is to enable the use of strong authentication for > all TLS connections over the internet. The certificates as > things-in-themselves don't really matter, they are actually just a vehicle to > post the public key of the user/server in a reliable public place. The > security occurs when the challenges to prove private key ownership are > cross-issued by each party. MITM would not have the private keys to answer > either challenge. > > Note that this still doesn't solve the problem of MITM obtaining the server's > private key. I'm still working on that one. > > I might be misunderstanding, but it seems to me that your global directory > would allow a passive listener to fingerprint the client by sniffing in a > variety of places -- near the client, near the server, or near the directory. > > If you assume an attacker interested in collecting metadata about the > clients, this would be suboptimal. > > I may be missing something, but this sounds like it is just a global, central > certificate authority, albeit one that is not actually issuing the > certificates, but still assigning them GUIDs, which are by definition > globally unique. > > Am I indeed missing something? > > Jon > > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
