On Tue, Jul 17, 2018 at 01:08:28PM +0000, Tim Hollebeek wrote: > Yes, the RFC 6844 grammar is a mess, and it has significantly impeded > efforts to improve CAA. It's one of the things I think is most important to > fix in 6844bis.
The main problem in my opinion with RFC6844 grammar is the examples that contradict it. Yes, the grammar does have the problem that it is ambiguous, but it seems that running into this problem is unlikely in real world, as the inputs required are pretty odd. In practicular, if someone tries to implment RFC6844 grammar: - They handroll the parser. With high likehood, the parser picks the obvious meaning of the input (because it is far the simplest to implement the parser that way). - They use parser generator, but accidentially misenter the grammar in a way that fixes the problem. With high likehood, this is also the obvious meaning (because it is the easiest to specify). - They use parser generator and correctly enter the grammar. In this case, the parser generator would probably complain about the grammar (most parser generators do not handle general context-free grammars). If the buggy parser makes it into production, it will still handle most of the inputs seen in the real world. > It is particularly troubling because CABF rules point to 6844, and some > people have been sticklers about requiring very strict compliance with RFCs > that are pointed to by the BRs. For 6844, it's often very unclear what's > compliant, as the document is often ambiguous, and contradicts itself and > other well-known RFCs! > > I'm a big fan of CAA (as long as it isn't used anti-competitively ...), but > 6844 has been an endless source of headaches. High quality analysis like > Ilari's will go a long way towards helping us make 6844bis much better... On the other hand, I find the existence of inputs that parse in both RFC6844 and RFC6844bis but differently quite troublesome. Especially given that these inputs are not necressarily rare in the real world. Also, if someone uses RFC6844bis CAA records containing multiple parameters with a CA that uses RFC6844 CAA records, that is likely discovered fairly quickly as the misparsed parameters probably cause things to blow up. However, if someone uses RFC6844 CAA records with multiple parameters with a CA that uses RFC6844bis CAA records and does not use parser that treat unparseable records as unsatisfiable or have handrolled parser that misparses the thing in a really whacky way, you have fail- open situation on your hands. I say that it would be nice if CAs treated issue records with unknown parameters or parse errors as unsastisfiable (as this makes errors much more likely to fail closed and fixed than to fail open and lurk as security problems). I do not offhand know if this is already required or not. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
