On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf@dessus.com> wrote:
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of routers and things have moved on, but it seems to me that the history of certificate management in routers is not a rich tapestry of triumph.
It’s not. I talked about this in the security area session at IETF several meetings ago — the requirements operators have around this space, and it’s quite a pain to be honest. I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap. The issue isn’t that most people want privacy, it’s they want transport integrity which in general the TLS community seems to think everyone NEEDS both.
Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address.
This is a whole mess of trouble here due to the disconnect in how routers are managed, the technical capabilities of vendors and where the protocol split lives here. I will take routers that don’t reboot when we commit them and devices that can be managed automatically vs the keyboard jockey days that we’re all used to.