I'm not an expert in TLS -- my technical background is SRP/AES. I thought every client already has a private key in order to negotiate with the server for a session key.
If that's not true, then yes, authentication by the server that the connection is with the client directly, and not through MITM, requires each user to have a private key. -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Thursday, September 12, 2013 10:23 To: Karl Malbrain Cc: [email protected] Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol Hi Karl, On 09/12/2013 06:13 PM, Karl Malbrain wrote: > I was under the impression that this list was to discuss things > pre-draft -- e.g. general concepts first, details later in a specific > work-group. I'm sorry if you find the piece meal approach difficult. Its not that its difficult but rather that another level of detail might be needed before its clear if the approach could work. (Being honest, I'm skeptical of anything that needs every client who uses TLS have a private key, if that is what's proposed.) > > My proposal in a nutshell: > > 1. Use TLS strong authentication between client and server on all > connections over the internet to obviate MITM attacks. 2. Make users' > public keys public information to obviate current TLS limitations on > obtaining them. > > If everyone agrees with this, we can certainly move onto a draft to > work out details, and yes, I'd need assistance from that point onward. I'd say the overall thrust of the idea is clear(ish), but you won't get rough consensus on something like that until after its written down (ideally with running code), so I reckon this is at the point where an I-D is the next step. So if you get others who're interested and who know how to do it, write up that I-D. (And again, if you're not sure how to do it yourself, just ping me.) S. > > Karl > > -----Original Message----- From: Stephen Farrell > [mailto:[email protected]] Sent: Thursday, September 12, 2013 > 09:47 To: Karl Malbrain Cc: Jon Callas; Theodore Ts'o; > [email protected]; Phillip Hallam-Baker Subject: Re: [perpass] proposed > enhancement to TLS strong authentication protocol > > > 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 > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
