On 10/21/19 11:04 AM, Jared Mauch wrote:
I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap.
I think that's an unfortunate state of affair. I don't know how to get around the PEBKAC problem.
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.
The biggest argument that I've seen is that you can't truly have privacy without integrity. Lest you be speaking over an encrypted channel with an unauthenticated MitM. My understanding is that authentication is the most important issue and that privacy is a nice add-on. With that in mind, I wonder if we couldn't have each router be it's own CA and issue /client/ certificates for and to each neighbor to use to authenticate back to the local router. This has the added advantage that you wouldn't need to worry about different routers trusting the same CA or bother with PKI. Everything would be local router centric. The neighbor would effectively be using a super fancy key that a neighbor provided for use when talking to said neighbor. I think that using /client/ certificates would also allow for certificate rotation in that the router can issue a new /client/ certificate while still trusting the existing /client/ certificate. Then once the client updates to using the new /client/ certificate, the router can revoke the old /client/ certificate using standard CRL methods. All of this would be centric to the local router. I suspect that it would likely be okay to have longer lived certificates in such a configuration. -- Grant. . . . unix || die