Ned Freed writes: > > Why is it a good idea to do an extensible protocol that we don't have > > any proposed extensions for? > > First, the protocol is already extensible, just not in the right way for this > case.
By which you mean? It doesn't have a "criticality" indicator for tags? > Second, what do you think the "non-V1 signatures in new fields" are if > they aren't extensions? Of course they're extensions, but not of an existing field. The process required to get them standardized is different. > This is all old and well-tread ground in many protocols, and > there's large amounts of "running code" saying that the issues you > imagine this will create don't actually occur in practice. I hope you're right. What worries me that I suspect that there really aren't all that many protocols whose purpose is to DoS illegitimate use, whose design is to DoS unauthenticated use, and where the set of legitimate uses is so much larger than the authenticatible set, as in the case of domain-based authentication. > (I have described the issues that have occurred, as well as why > that won't happen here.) Actually, no, you haven't. I accept your expertise, but I've seen insufficient evidence to lead me to the same conclusion in your absence. > Given that that this need has arisen, it seems to me that solving > the general problem in a clean way makes a lot more sense than a > one time hack, especially since the implementation costs are, > AFAICT, nearly identical. Why do you think the general problem can be solved "cleanly"? I agree that a clean syntax can be constructed, and that it could be reused for a lot of different individual problems that seem to be amenable to DKIM-signature-based solutions. But the domain of the "general problem" seems to be unknown, and the specific example we have (third party authorization via in-band protocol) is fraught with external semantic issues (criteria for authorization, how to populate those lists, etc). I see no reason to suppose that other problems won't have critical external semantics as well, and those leading to conflicting requirements. As soon as you have multiple signatures for various purposes, you have potential for unwanted interactions where one signature may validate even though it's the wrong purpose, as we've seen with "token signatures" in this discussion. I don't really see good reason to expect a semantically clean solution. While semantic confusion is no excuse for ugly syntax, I remain worried that use of one syntax for multiple semantics will lead to more confusion than cleanliness. I'd be a lot happier if we had another example of the "general problem" to help justify claims that these tags really are a "polymorphic" solution for a class of similar problems rather than C++ style arbitrary "overloading" of syntax. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
