<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Mar 16, 2014, at 2:58 PM, Christian Huitema <<a href="mailto:huitema@huitema.net">huitema@huitema.net</a>> wrote:<br><blockquote type="cite">This comes down to "detecting MITM." You could indeed use client<br>certificates. You could also use some form of password check that is secure against MITM, e.g. EKE. But the client authentication tends to happen outside of the TLS exchange, because it is a somewhat complex user<br>interaction.<br></blockquote>I'm actually not suggesting using (a) TLS as it stands; (b) client certificates as a way of authenticating the client in a traditional sense.  Rather, the client cert exist solely to provide a mechanism for the client to send an unforgeable (without attacks on parts of the system that don't currently need to be attacked) message to the server.  This would be automatic - effectively an additional round in a TLSX session setup.  It can be piggy-backed on the first client-to-server message, though that does increase the risk as that message would be visible to the MITM.<br><br>Servers already *do* place information on clients to let them detect "known" machines.  This becomes one other authentication factor; when it isn't available, sites may ask security questions or whatever.  That, however, is static data which can simply be forwarded by the MITM.  By using the same kind of approach but tying it to a particular connection as seen by the two end nodes, we can make it impossible for the MITM to forge.<br><br><blockquote type="cite">What if this is the first time the client connects to the site?<br></blockquote>Explicitly not covered by this proposal.  A true "first connection" with no previously shared information and no mutually trusted third party (effectively, an introducer) is an incoherent concept anyway.<br><br><blockquote type="cite">What if they just start using a new device?<br></blockquote>Then they aren't protected.  Though providing a way to export and import the information on a USB stick or whatever seems easy enough.  You can even imagine techniques for transferring it over a network, though this gets tricky.<br><br><blockquote type="cite">What if they forgot their password?<br></blockquote>There's no password for the user to forget in my proposal.<br><br>Given a client cert, you *could* decide to use it in place of the password.  In general, that's a *bad idea*, as it means a stolen laptop gives immediate access to tons of websites.  Of course, if you store the client certs in something akin to a password safe - which the user has to unlock - then both the user experience and the safety are pretty much as they are today.  (Note, BTW, that many password safes sync over the Internet.  That might be OK here *with* the proviso that the crypto used doesn't just prevent reading a stolen copy of the safe - it prevents a MITM modification that modifies or even just adds a new client cert.  I doubt any existing implementations have worried about that problem - though with autofill for account names and passwords, perhaps they should.)<br><br><blockquote type="cite">If client authentication is implemented outside the TLS exchange, what API do we have to tie the client verification to the TLS credentials and negotiated keys?<br></blockquote>None.  The only thing this is designed to do is make MITM attacks harder.<br><br><blockquote type="cite">Detection inside the second automated TLS exchange could also rely on<br>"re-negotiation." If the MITM attack does not happen all the time, it will lead to renegotiation failure, and that can be detected.<br></blockquote>I don't follow this.<br><br>And also:<br><br><div>On Mar 16, 2014, at 2:51 PM, Hanno Böck <<a href="mailto:hanno@hboeck.de">hanno@hboeck.de</a>> wrote:<br><blockquote type="cite" style="font-family: monospace;">Yes. We had this technology for ages and nobody is using it.<br></blockquote>Which technology?  Clients certs have certainly been around for years, but </div><div>I'm suggesting a non-standard use for them.</div><div><br><blockquote type="cite" style="font-family: monospace;">The problem is: Users don't use a single browser. And transferring<br>certs from one browser to another is hard in a user-friendly and secure<br>way. Just think of internet cafes or people using random foreign<br>computers to log into their webmail. (that's a security nightmare on<br>its own without any relation to tls, but that's the way it is)<br></blockquote>Frankly, if we spend our time worrying about how to secure things that are inherently unsecurable, we'll make no progress at all.  I don't really care about the security of someone who reads his mail on some machine he has no reason to trust.  *He* clearly doesn't - it's not like the hazards aren't obvious once explained (and they *have* been explained many times) even to the technically unsophisticated.  If he wants to take the risks, fine - but his willingness to live with high risk shouldn't block the rest of us from building things better.</div><div><div>                                                        -- Jerry</div></div><div><br></div></body></html>