Victor Duchovni <[EMAIL PROTECTED]> writes: >This, in my view, has little to do with ASN.1, XML, or other encoding >frameworks. Thorough input validation is not yet routinely and consistently >practiced by most software developers. Software is almost invariably written >to parse formats observed in practice correctly, and is then promptly >declared to "work".
It's not just this, sometimes the acceptance of not-quite-correct data is necessary, because if you don't do it, your implementation breaks. To take one well-known example, Microsoft have consistently encoded the version info in their SSL/TLS handshake wrong, which in theory allows rollback attacks. So as a developer you have the following options: 1. Reject the encoding and be incompatible with 95(?)% of *all* deployed SSL clients (that's *several hundred million* users). 2. Turn a blind eye and interoperate with said several hundred million users, at the expense of being vulnerable to rollback attacks. I'm not aware of a single implementation that takes option 1, simply because it would be pure marketplace suicide to do so. The same goes for pretty much every other security protocol I know of. SSH is the most explicit since clients and servers exchange ASCII strings before they do anything else, all SSH implementations have a built-in database of known bugs that they adjust their behaviour for when they detect a certain client or server. Obviously no-one will implement this bug-compatibility for a security hole, but it's not impossible that some of this extended flexibility may at some point lead to a problem. For other protocols, it works in reverse, you recognise the peer implemention by the bugs, not the other way round. Beyond straight implementation bugs though are standards that require insecure or ambiguous behaviour, either by accident (which eventually gets fixed), or because of design-by-committee politics, about which enough has probably been said in the past (cough*IPsec*cough :-). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]