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
