On 10/22/2019 14:07, Keith Medcalf wrote:
That is incorrect.
I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo".
At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up.
The Security part in Transport Layer Security is Encryption. Authentication is lathered on top as an afterthought and requires external measures be taken in order to have*any* effect whatsoever.
This is unauthenticated Diffie-Hellmann key agreement, essentially. As has been pointed out, it only works if you know that, during the initial agreement, you can trust that you are talking directly to who you want to talk to without fear of a man in the middle (a passive observer will still be foiled). TLS supports this in the form of anonymous TLS. Something similar is normally used for opportunistic TLS upgrade with e.g. SMTP, but there at least one end (the "server") still presents a certificate; the client just doesn't validate it. Password-authenticated DHKA fixes the above problem, but then you're back to the status quo of a preshared secret. This is, in fact, how the DHE* suite of TLS ciphersuites works, AFAIK. Use PKI to exchange one secret (with trust of who you're talking to, where applicable, due to the PKI), then use authenticated DH to establish a session secret using that as the PSK. Then throw away that session secret when you're done. One thing that comes to mind in the context of what others have done is to have each router maintain, internally, its own long-term CA and issue a peer certificate when a session is first started to its peer. This has the same problem in that the initial session establishment could be meddled with but, assuming that does not happen (and it does not, in practice, seem especially likely except maybe on an IX), the peer can identify itself for the long term. THrow alarm bells if an unknown peer again tries to talk on that configured peer. That at least gets you some form of long-term security (at the cost of possibly NO security if the above assumptions are not met), and it happens automatically. You could do the same thing with a symmetric secret being automatically established using DHKA or similar, too, of course. -- Brandon Martin