> 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?
I mean that any implementor can add whatever previously undefined tags
they want to a signature and still be fully compliant. The meaning of those
tags could then be taken to be whatever anyone eants by bilateral agreement.
Semantics and requirements can also be attached to signatures through external
means like publishing DNS records, as DMARC did.
In other words, the issues you seem to be worried about criticality indicators
introducing already exist.
> It doesn't have a "criticality" indicator for tags?
All criticality indicators would do, essentially is tell people when a
signature has to be *ignored*.
> > 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.
Really? How does it differ? In either case you have to write a
specification and get it through the IETF process.
> > 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.
OK, let's say for the sake of argument that this is true - the question then
is why would that mean that adding criticality indicators is a bad idea?
> > (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.
Then you need to reread my original message on this topic, where I covered the
one previous adverse/perverse outcome I'm aware of in this space. And if you
don't understand the difference between semantics requiring something be
ignored and semantics requiring something be rejected, there's really
nothing more I can say.
And anything beyond examination of previous failures amounts to trying to prove
a negative.
> > 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.
That's the general problem I'm talking about. So it seems we agree
it can be solved cleanly.
> 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.
In which case you define new critical tags to specify those semantics.
> 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.
Of course it's necessary to properly design and specify future extensions. Any
concievable mechanism carries with it the potential for misuse.
> 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.
Yes, it's always nice to have more data to base decisions on. Are you
prepared to wait for more data to show up before acting? Based on the
current rate, that would mean waiting several years at least.
Finally, since this conversation is essentially out of order at the present
time - we're supposed to be discussing the DMARC charter - this will be my
final message on this topic.
Ned
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
