6 ms·

The robustness principle is widely considered to be a bad practice these days. Strictly failing is a good thing, generally. Accepting arbitrary query parameter

by treve 6y ago

The robustness principle is widely considered to be a bad practice these days. Strictly failing is a good thing, generally. Accepting arbitrary query parameters is pretty much a de facto exception though

raxxorrax 6y ago
You have to ensure you don't over-engineer specifications or it will be ignored as well. HTTP requests are one thing, imagine if we were strict on HTML validation. We now have robust browsers and I am not sure if that is only a bad thing. Although it would be nice if people would check their documents once or twice. edit: I don't think considering the principle as bad is a sensible approach as it doesn't mean to ignore errors in theory.
- klodolph 6y ago
  > imagine if we were strict on HTML validation You don't have to imagine it, this actually happened. I don't remember the details, but back in the HTML 4 era, there was XHTML, and if you gave it an XML media type, many browsers would parse it as XML and reject the entire document if there was any error (and display nothing at all but an error message). There were a number of articles and blog posts about this back in the day.
dfee 6y ago
I feel that you’re right - it’s increasingly considered bad practice - but I’ve not seen this conversation play out. Of course, this often comes up in collaborative coding exercises (work, open source), so seeing a discussion on the topic would be helpful. Anyone have a link to such a discussion?
- daurnimator 6y ago
  https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
nmadden 6y ago
As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted security best practice now to use PKCE [1] on all authorisation requests [2]. However, despite the OAuth spec saying that authorisation servers MUST ignore unrecognised parameters [3], there are many major services that fail if you add a PKCE code_challenge parameter. This means generic client libraries either don't implement PKCE or have to maintain a list of sites that don't work (which gets stale over time) or have some risky downgrade logic. So there is a tradeoff between strict validation and allowing future expansion and upgrades. By all means strictly validate the parameters you need, but maybe don't reject parameters you don't recognise. [1]: https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ [2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... [3]: https://tools.ietf.org/html/rfc6749#page-19 https://tools.ietf.org/html/rfc6749#page-19
- crote 6y ago
  The same thing happened with TLS! TLS 1.2 has a field for the protocol version during negotiation. The spec says that you're supposed to proceed with the lower version if the other party claims a version higher than yours. Turns out in practice that some implementations just decided to give up instead. This meant that it wasn't possible to increase the version number for TLS 1.3, because advertising it would break a lot of people's connectivity. Instead, TLS 1.3 uses the 1.2 version, and added ANOTHER field containing the real version. So Google introduced GREASE in RFC 8701. Long story short, Chrome now advertises a bunch of bogus extension values, thus making sure that implementations can't simply ignore unknown values. This makes it a lot more likely that future cipher additions will not break older clients, which is pretty damn important for something as critical as TLS.
  - sneak 6y ago
    I often wonder why implementors do such hacky gymnastics instead of just breaking the clients of the corps that use janky noncompliant middleboxes and causing people to replace their broken shit. Other than those corps who bought crap, nobody would blame Google, for example, and I bet those orgs would only do so temporarily. Make life slightly more difficult for those whose poor decisions CAUSED the ossification.
tialaramex 6y ago
If you're designing things where you expect this to be an issue you can do a few things to ease your path: Firstly you want to have a clear distinction between "Things that it's fine to just ignore because you don't understand them" and "Things that if you don't understand them that means you're screwed, abort". For example in PNG some of the bitflags cunningly concealed in the capitalisation of the extension chunk names indicate whether it's OK to just ignore the chunk if you don't understand it, and whether it's OK to just copy this chunk across into a modified image without understanding it. In X.509 there's a bitflag that means "If you don't understand this part of the certificate then you mustn't rely on the certificate at all". Then you need a way for people to agree on how to allocate the extensions. The IETF has an impressive array of different mechanisms available, from "You need to actually write and publish a Standards Track document" to "First Come First Served" which suit different purposes. Consider just copying some or all of them. https://tools.ietf.org/html/rfc8126 https://tools.ietf.org/html/rfc8126 TLS had big problems with (non-)interoperability and as a security feature couldn't just shrug and put up with never moving forward so it had to endure painful upgrades each time. This time they got GREASE (RFC 8701) to try to stop this ever happening again. Basically they agree how to extend things, then, reserve some of the extension namespace and routinely shove crap into it on purpose. Things that properly understand how extensions work will go "Eh, I don't understand this" and ignore the crap. Everything else explodes, and you catch the explosions early because they happen everywhere all the time with all the GREASE you're using. GREASing new features has become a go-to strategy and you should consider this too. For example Encrypted Client Hello (the current iteration of ESNI) is intended to be used for all connections. Basically every server you talk to, you always say "Also here's an encrypted hello". Maybe the server can read it and the plaintext hello was just a dummy - maybe it just reads the plaintext hello, an eavesdropper can't tell. So if they want to block encrypted hello, they have to block everything, even though probably very few servers will offer this feature at first.

by treve 6y ago

raxxorrax 6y ago

You have to ensure you don't over-engineer specifications or it will be ignored as well. HTTP requests are one thing, imagine if we were strict on HTML validation. We now have robust browsers and I am not sure if that is only a bad thing. Although it would be nice if people would check their documents once or twice. edit: I don't think considering the principle as bad is a sensible approach as it doesn't mean to ignore errors in theory.

klodolph 6y ago
> imagine if we were strict on HTML validation You don't have to imagine it, this actually happened. I don't remember the details, but back in the HTML 4 era, there was XHTML, and if you gave it an XML media type, many browsers would parse it as XML and reject the entire document if there was any error (and display nothing at all but an error message). There were a number of articles and blog posts about this back in the day.

dfee 6y ago

I feel that you’re right - it’s increasingly considered bad practice - but I’ve not seen this conversation play out. Of course, this often comes up in collaborative coding exercises (work, open source), so seeing a discussion on the topic would be helpful. Anyone have a link to such a discussion?

daurnimator 6y ago
https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...

nmadden 6y ago

As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted security best practice now to use PKCE [1] on all authorisation requests [2]. However, despite the OAuth spec saying that authorisation servers MUST ignore unrecognised parameters [3], there are many major services that fail if you add a PKCE code_challenge parameter. This means generic client libraries either don't implement PKCE or have to maintain a list of sites that don't work (which gets stale over time) or have some risky downgrade logic. So there is a tradeoff between strict validation and allowing future expansion and upgrades. By all means strictly validate the parameters you need, but maybe don't reject parameters you don't recognise. [1]: https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ [2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... [3]: https://tools.ietf.org/html/rfc6749#page-19 https://tools.ietf.org/html/rfc6749#page-19

crote 6y ago
The same thing happened with TLS! TLS 1.2 has a field for the protocol version during negotiation. The spec says that you're supposed to proceed with the lower version if the other party claims a version higher than yours. Turns out in practice that some implementations just decided to give up instead. This meant that it wasn't possible to increase the version number for TLS 1.3, because advertising it would break a lot of people's connectivity. Instead, TLS 1.3 uses the 1.2 version, and added ANOTHER field containing the real version. So Google introduced GREASE in RFC 8701. Long story short, Chrome now advertises a bunch of bogus extension values, thus making sure that implementations can't simply ignore unknown values. This makes it a lot more likely that future cipher additions will not break older clients, which is pretty damn important for something as critical as TLS.
- sneak 6y ago
  I often wonder why implementors do such hacky gymnastics instead of just breaking the clients of the corps that use janky noncompliant middleboxes and causing people to replace their broken shit. Other than those corps who bought crap, nobody would blame Google, for example, and I bet those orgs would only do so temporarily. Make life slightly more difficult for those whose poor decisions CAUSED the ossification.

tialaramex 6y ago

If you're designing things where you expect this to be an issue you can do a few things to ease your path: Firstly you want to have a clear distinction between "Things that it's fine to just ignore because you don't understand them" and "Things that if you don't understand them that means you're screwed, abort". For example in PNG some of the bitflags cunningly concealed in the capitalisation of the extension chunk names indicate whether it's OK to just ignore the chunk if you don't understand it, and whether it's OK to just copy this chunk across into a modified image without understanding it. In X.509 there's a bitflag that means "If you don't understand this part of the certificate then you mustn't rely on the certificate at all". Then you need a way for people to agree on how to allocate the extensions. The IETF has an impressive array of different mechanisms available, from "You need to actually write and publish a Standards Track document" to "First Come First Served" which suit different purposes. Consider just copying some or all of them. https://tools.ietf.org/html/rfc8126 https://tools.ietf.org/html/rfc8126 TLS had big problems with (non-)interoperability and as a security feature couldn't just shrug and put up with never moving forward so it had to endure painful upgrades each time. This time they got GREASE (RFC 8701) to try to stop this ever happening again. Basically they agree how to extend things, then, reserve some of the extension namespace and routinely shove crap into it on purpose. Things that properly understand how extensions work will go "Eh, I don't understand this" and ignore the crap. Everything else explodes, and you catch the explosions early because they happen everywhere all the time with all the GREASE you're using. GREASing new features has become a go-to strategy and you should consider this too. For example Encrypted Client Hello (the current iteration of ESNI) is intended to be used for all connections. Basically every server you talk to, you always say "Also here's an encrypted hello". Maybe the server can read it and the plaintext hello was just a dummy - maybe it just reads the plaintext hello, an eavesdropper can't tell. So if they want to block encrypted hello, they have to block everything, even though probably very few servers will offer this feature at first.