On Mon, Jul 06, 2015 at 11:32:26AM -0700, Derick Winkworth wrote: > Note section 6. > > The authors of the draft propose replacing this maxim with: > > "Protocol designs and implementations should be maximally strict."
Neat. Great first step. It's probably not that simple. It would be wise to study variations in widely deployed protocols with a great deal more detail than the HTTP/1.1 spec: Zalewski's "The Tangled Web" Ivan Ristic's "Bulletproof TLS/SSL" nmap TCP/IP fingerprinting In general, DWIM (error-correcting) systems are probably dangerous, but unfortunately common with browsers due to poor HTML practices in the early days. Good idea at time or not, this negatively affects us today. Another issue is market-leading software non-compliance. For example, you can't read most of my emails on an iPad because it does not show multipart MIME emails. Outlook shows my signatures as attachments with the filename ATTrandomnumber.DAT which confuses people even when I explain it in my signature file. Exchange cloud silently drops them. I've not signed this email so that such people can actually read it. Typically, OS vendors simply don't care about products beyond some work/marketshare threshhold, whereas optional software must work better to get people to download it. I'm wondering if I should simply give up. How to incentivize large market-making "good enough" vendors to implement the full spec or none at all is an interesting question. Actually this RFC points to incentive structure but only implicitly. It is the only way to fix these problems - c.f. Ross Anderson's Security Economics publications. It's often safest for systems to parse into an intermediate form (AST tree) using only known extensions and tags and reserialize using a very conservative (strict) encoding, which is half of Postel's Maxim. TLS has an interesting method for distinguishing, at the protocol level, a required versus optional tag (in the TLV format), so that an implementation can decide to fail or ignore the tag/extension. This subject (protocol design for robustness in the face of variegated implementations) needs vastly more study by some polymaths who can work at both high and very low levels. In particular, concerns revolve around: Undefined behavior Implementation-defined behavior Ambiguous wording in the standard Implementation mistakes Where to check inputs / preconditions / validity Dealing with incorrectness The idea of where to check input is interesting. Trying to check preconditions at every function entry point can lead to extremely brittle code. Some things like randomness are properties of the source (provenance) not testable properties of the data itself. On the last point, see Ferguson and Schneier, Cryptography Engineering, esp. Sec 8.4.3 Assertions. How to respond to invalid inputs is hard. Simply exiting is not always a good idea. What if you are a security monitoring system? OS kernel? A plug-in library that runs in-process in the browser (which would take out every tab)? What if exiting and respawn trigger resource consumption? How to merely report an error is hard too. For example, trying to mount a filesystem on Unix once gave me "mount: invalid argument". This turned out to be perror of the EINVAL errno, which was a response to the mount system call, not the userlevel application. The error was confusing because it was not contextualized. Merely describing an ideal form for an RFC is an interesting exercise. English is often too ambiguous. It seems that one needs to create multiple ways of describing the desired behavior (e.g. state machines, English wording, etc.) as well as supporting rationale (what you are trying to accomplish and what you are trying to prevent) to provide maximal redundancy and context. Ideally, then, the RFC could be be checked for internal consistency during the draft process. One could easily write a book on the subject. -- http://www.subspacefield.org/~travis/ | if spammer then j...@subspacefield.org "Computer crime, the glamor crime of the 1970s, will become in the 1980s one of the greatest sources of preventable business loss." John M. Carroll, "Computer Security", first edition cover flap, 1977 _______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
