It's a bad idea and people shouldn't build it into new systems. Version the protocol instead, and plan on making it straightforward to upgrade the protocol and lock out old versions.
It's a bad idea and people shouldn't build it into new systems. Version the protocol instead, and plan on making it straightforward to upgrade the protocol and lock out old versions.
That being said, for most purposes, you can do worse than using either mutual TLS or Macaroons [0]. As always with cryptography though, the devil is in the details, so for a more thorough discussion, check out @tptacek's "A Child's Garden of Inter-Service Authentication Schemes" [1]. It's one of my favourite treatments of the topic, and discusses the tradeoffs of a few different techniques for different use-cases.
[0] https://en.wikipedia.org/wiki/Macaroons_(computer_science)
I don’t think it’s just a crypto thing, agility is an issue in protocols that need to remain compatible in general.
While on one hand insecure LDAP is convenient for testing, I do think it should really just be removed and require LDAPS.
It's why I still test my websites with Netscape 3.x and keep http running.
> Be conservative in what you send, be liberal in what you accept.
The first half makes good sense. You should make efforts to ensure your program is producing well-formed output. That's just a statement of software quality.
The second half is dependent on the problem domain. A web browser should do its best to cope with malformed input, sure. An Ada compiler should not, as an important part of its job is to reject erroneous inputs. Similarly, part of the value of XML schemas is to (at least partially) automate the process of detecting invalid data, perhaps so that bad requests can be rejected.
edit Turns out others have spent more time thinking about this than I have: https://en.wikipedia.org/wiki/Robustness_principle#Criticism