Subject: [dmarc-ietf] The theory of DKIM versions

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2014 19:20:17 -0400

> I'm uneasy with an increase in version that isn't done in a complete
> replacement for RFC6376.

The problem may be that we don't agree about what DKIM versions mean. 
Here's what I would like them to mean:

a) The lexical syntax of DKIM signatures will never change, and a v=1 
parser will aways be able to find and parse all of the tags in a 
signature.  (If you need to change the syntax, invent a new header name.)

b) We will never change the meaning of defined tag.  (If you want a tag 
that means something different, define a new one.)

c) Whenever we add new tags that require that the verifier understand them 
to get the right answer, we increment the version number.

d) Versions are cumulative.  Every signature that is a valid version N 
signature is still a valid version N+1 signature, give or take the change 
in the b= hash due to the version bump.

Key records don't need version numbers, since a key should only be used by 
signatures at a version high enough to handle whatever is in the key.

This sort of versioning seems to work fine for file systems and other 
constructs where there's no feedback from the reader back to the writer. 
Either the reader can deal with it, or not.  But a version bump is not a 
big deal, and doesn't require reissuing the whole spec.

I can think of a variety of ways to get this effect by hacks that stay at 
v=1, e.g.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2014 23:51:08 -0000

sigh, stupid editor.  As I was saying:

I can think of a variety of ways to get this effect by hacks that stay
at v=1, all rather ugly.  For example, we could invent
pseudo-canonicalizations like c=condrelaxed/condsimple which are the
same as relaxed and simple, but only are valid if the verifier also
understands the cs= condition.  But really, ugh.  

This sort of thing will doubtless come up again, and it doesn't seem
hard to do an extension framework that is simple but does what we need
it to do.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jun 2014 18:34:42 -0700

On Thu, Jun 19, 2014 at 4:20 PM, John R Levine <[email-masked]> wrote:

> [...]

Actually I think I agree with most or all of that.  My concern has to do
with where a DKIM neophyte goes to get a complete description of DKIM.  If
we do what your draft proposes, then the complete definition will lie in no
less than two documents, plus any that register extension tags or values.
So what I'm uncomfortable with is a v=2 document that is nothing more than
a changes-since-v=1.

Think of it as software: For big important changes where cross-version
compatibility is a question, it's typical to do a vX.0 release, not just
send out one or more patches that one has to be sure to collect to see the
whole thing.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2014 21:44:57 -0400

> with where a DKIM neophyte goes to get a complete description of DKIM.

He goes to 6376, and should notice the "updated by" in the RFC index. 
There's a bazillion RFCs updated by later RFCs so this doesn't seem unduly 
difficult.

As incremental RFCs go, this is pretty simple.  Try and find all the RFCs 
you need to implement SASL for AUTH in SUBMIT, for example.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 20 Jun 2014 13:41:53 +0900

> in the b= hash due to the version bump.

I think this is unnecessarily restrictive.  It's unnecessary because a
verifier that wants to handle multiple versions can always incorporate
a routine per version.  It's restrictive because a later version might
want to disavow an earlier version.

For example, v2 might REQUIRE that signatures enforce the RFC 5322
limit of one on From, To, Cc, and Message-ID, which would be
incompatible with v1 signatures that don't do so.  (Don't take that
example too seriously.  Use of "cumulative versions" requires
demonstrating nonexistence, or at least "nonimportance", of *any*
example of desirable incompatibility.)

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Jun 2014 10:46:41 +0200

On Fri 20/Jun/2014 03:34:42 +0200 Murray S. Kucherawy wrote:
> 
> Actually I think I agree with most or all of that.  My concern has to
> do with where a DKIM neophyte goes to get a complete description of
> DKIM.  If we do what your draft proposes, then the complete definition
> will lie in no less than two documents, plus any that register
> extension tags or values.  So what I'm uncomfortable with is a v=2
> document that is nothing more than a changes-since-v=1.

As I understand it, the reason we'd like to associate DKIM-Delegate
with a version bump is to guard those verifiers who don't expect weak
signatures.  OTOH, Dave's "very-relaxed" canonicalization does have
some real grounds.  DKIM verifications can fail unexpectedly, albeit
infrequently, which is why DKIM-Delegate-00 offered to overload z=.

As Dave's proposal implied, new c14ns are part of the extensibility
already provided for.  Section 3.4 says:

                                           Further canonicalization
   algorithms MAY be defined in the future; Verifiers MUST ignore any
   signatures that use unrecognized canonicalization algorithms.

The document defining the new c14n is formally separated from the one
which defines weak signatures.  The latter can simply recommend using
the former, thereby achieving the desired protection.

Ale

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2014 09:11:54 -0400

> want to disavow an earlier version.

If you want to change the semantics that much, like I said, give it a 
different name.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2014 19:13:18 -0000

>Here's what I would like them to mean: ...

>to get the right answer, we increment the version number.

Ned pointed out that we could add an indicator on a tag that means
that interpreting the tag is mandatory, so if the verifier doesn't
understand the tag, the verification fails.  This would decrease the
need for future version bumps.

So for example:

DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example;
   h=From:To:Date; l=0; !cs=fs; fs=t; 
   bh=...
   b=<this is a "weak" forwarding signature that covers part of the message>

The ! in !cs= means that the verifier MUST handle the cs= tag or fail the message.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 20 Jun 2014 13:15:30 -0700 (PDT)

> The ! in !cs= means that the verifier MUST handle the cs= tag or fail the message.

First, credit where credit is due: This is basically the criticality indicator
found in X.400, X.500, and various other protocols. The idea dates back to at
least the mid-1980s, if not earlier.

Second, I didn't originally mention this because I intended to propose adding
it, but having thought about it, I find myself liking the idea, especially
since it gives you a more general capability-based mechanism for future
extensions. In fact I could see this effectively obsoleting the version
field in DKIM.

Since there's substantial operational experience with this sort of mechanism -
not all of it good - it's important to access it in light of that previous
experience.

The obvious issue is that it makes it possible to create myriad incompatible
but nevertheless legitimate variants of DKIM. Since an important aspect
of DKIM is use by bilateral agreement, and since nothing prevents you
from attaching multiple DKIM-Signature header fields, even if this
happens I don't see it as a problem.

A second, more subtle, issue, and one that definitely happened in the X.400
space, is that the way this stuff ended up getting deployed created incentives
for implementations to simply ignore the criticality bit. This happened because
in an effort to create vendor lock-in several implementations decided to
decorate all their messages with critical extensions containing who knows what.
None of this stuff seemed to matter; messsages could be read and processed in
spite of it. So the result was a lot of processors simply ignored the
criticality, or at least could be set to do so.

I don't see this as likely to happen with DKIM for several reasons. For
one thing, the failure to interpret a paritcular DKIM-Signature field isn't
supposed to render the message unprocessable - in fact it's required that
it not have that effect. And there's so much flexibility along so
many other axes - multiple DKIM-Signature fields, fields with different
names, etc., that I don't see a serious concern here.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 12:51:35 +0900

> If you want to change the semantics that much, like I said, give it a 

Like I said, it's unnecessary.  Why do you think it's better to
proliferate field names?

AIUI, what you're proposing here is a major change from the way the
RFCs I've seen are constructed.  They say, the protocol must be
interpreted exactly as in this document and for any different version
all bets are off, but of course an agent may choose to support
multiple versions.  It's a matter of designer judgment whether the
incompatibilites are sufficient to warrant a new name.  This has
worked well enough for the Internet so far AFAICT.

Why do you think DMARC is an appropriate place to experiment with a
different interpretation of version numbering?  I note your file
system example, but it seems to me that is fundamentally different in
that not only the protocols but the reference (and typically dominant)
implementation are controlled by the same entity, and furthermore,
layering is much more accurately enforced in OSes than on the Internet.

I noted Ned Freed's comment about "MIME-Version: 1.0" being a mistake,
but security protocols are a different use case, and I think it's best
to control extensions very carefully.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 14:42:33 +0900

Ned Freed writes:

 > The obvious issue is that it makes it possible to create myriad
 > incompatible but nevertheless legitimate variants of DKIM. Since an
 > important aspect of DKIM is use by bilateral agreement, and since
 > nothing prevents you from attaching multiple DKIM-Signature header
 > fields, even if this happens I don't see it as a problem.

Multiple signatures with the same basic semantics ("the domain in 'd='
vouches for the mailbox in From:", to paraphrase Dave Crocker) from
the same signatory clearly increases complexity, of handling for third
parties as well as of interpretation by recipients.

The scenario that worries me is not that Yahoo! will choose to apply
GMail-style conditions in a separate DKIM-Signature field from their
"native" DKIM-Signature field.  It's the scenario where they *don't*,
and Mediators (and Recipients) have to adjust to new "critical" tags
every time a large mailbox provider has a protocol brainstorm or
suffers a security breach.

 > I don't see [ignoring criticality] as likely to happen with DKIM
 > for several reasons. For one thing, the failure to interpret a
 > paritcular DKIM-Signature field isn't supposed to render the
 > message unprocessable - in fact it's required that it not have that
 > effect.

By design, DMARC renders that requirement inoperative, and a
"p=reject" policy is intended to render messages unprocessable exactly
when a particular DKIM-signature is invalid.  DKIM may not need to
worry about it, but we do.

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Jun 2014 08:46:19 -0700 (PDT)

> suffers a security breach.

The scenario you propose makes no sense: If Yahoo! or whoever does what
you describe, their messages would in effect have no attached signatures
until the receiving systems out there upgrade their software to handle
the new critical tags.

You can't count on much from large players, but I think you can count on them
not intentionally screwing themselves over.

> worry about it, but we do.

You're missing the point. We're *changing* the design here so things no
longer work this way by associating this with a version bump. And we've
already confirmed that a significant number of implementations ignore
v=2 signatures.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 21 Jun 2014 12:19:36 -0400

> not intentionally screwing themselves over.

I'm with Ned.  I know a lot of the relevant people at large public mail 
providers, who are under all sorts of internal political pressure, but 
they are not stupid. They will not break things for the sake of breaking 
them.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 22 Jun 2014 12:16:46 +0900

John R Levine writes:

 > They will not break things for the sake of breaking them.

Of course not.  They'll break *some* things for the sake of dealing
with *other* breakage that's more important to them.  I don't see a
good reason for thinking that they'll agree on the "other breakage",
either.  GMail participates in DMARC but mitigates by disrespecting
"p=reject", a central protocol of the policy part of DMARC.  Yahoo! 
participates but Yahoo! Groups mitigates by moving the mailbox into
the display name, as specifically deprecated by the DMARC FAQ.

Remember, I'm here with a specific commission: to advocate the
interests of mailing lists, as understood by the Mailman developers.
I've said that several times.  We are among the folks worst harmed by
Yahoo!'s and AOL's actions.  I see no reason to expect them to change
their definition of "less broken than the alternative" to emphasize
us.  If the IETF chooses to side with them, and offer its sympathy but
no help to us, fine -- not every problem has a solution satisfactory
to all parties.  But I'm not going to accept an *assumption* that
everything is going to work out fine "because nobody *wants* to break
things."  Explain why goodwill will make things work for us.  Please!

AIUI, at this point[1] we have *one* protocol we want to provide and
*no* validating experience (see Murray's response to your version bump
examples) for "cumulative versioning" in Internet protocols.  Ned
himself declares knowledge of "extensible" protocols with "critical
overrides" that ended in fragmentation and failure of interoperability.
(Though he declares that he thinks the DKIM/DMARC circumstances are
different, as presented so far that's just opinion, even though it is
an expert's opinion.)

We know that this particular set of protocols is controversial and
failure of interoperability causes real harm to *third parties*.  I
don't see a good reason for experimenting with "extensible protocols"
and "protocol versioning", at the same time as we're struggling with a
problem that is in itself very hard and high-risk.

Regards,
Steve

Footnotes: 
[1]  Evidently Dave Crocker has a much wider view of the mission of a
potential working group, but over the last couple of weeks discussion
has focused on delegation and third-party authorization.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 22 Jun 2014 09:54:29 +0900

Ned Freed writes:

 > The scenario you propose makes no sense:

True.

 > If Yahoo! or whoever does what you describe, their messages would
 > in effect have no attached signatures until the receiving systems
 > out there upgrade their software to handle the new critical tags.

No, they'll have effective signatures.  They'll use "v=1" signatures
as well during a transition period (they work well enough to be used
for a while ), and then do what they're doing now: tell their users to
yell at recipients who don't handle vendor-specific "V=2" signatures
to get their act together and "be part of the solution".

 > You can't count on much from large players, but I think you can
 > count on them not intentionally screwing themselves over.

I don't see the strategy above as screwing a large player more than
publishing p=reject already does.  They did that.

 > already confirmed that a significant number of implementations ignore

Changing the design of what?  I wish we could change the design of
DMARC[1], but I don't think that is going to happen.  DMARC is a
private agreement so far completely out of IETF control, it is known
to suck in some ways for third parties, and the big players are doing
those sucky things anyway because it accomplishes their goals without
hurting them very much.  Changing DKIM is not going to change DMARC as
far as I can see.  DMARC may adopt new features of DKIM, but only as
it serves the consortium's purposes, and they will surely continue to
apply the "p=reject" override to any "v=2" DKIM signature that fails
(generalized) identity alignment or is invalid.  No?

All the evidence I see says that even if the exact scenario I propose
is unlikely to occur, it's possible, maybe even quite probable, that
the big players will use the possibility of registering values and
imposing criticality to serve their own purposes.  You describe the
same kind of thing happening in the past -- I understand that "that
was then, this is now (and different)", but this "difference" is all
hypothetical.  The fact is that fragmentation does occur under some
circumstances.

Footnotes: 
[1]  In some ways.  Mostly I think it does what it's supposed to do
quite well, and I don't think I'd even change "p=reject" except to add
an explicit caveat that publishing "p=reject" means that the Author
Domain must assume *full* responsibility for lost or undelivered mail
in the current Internet environment.

---

From: Ned Freed <[email-masked]>
Date: Sun, 22 Jun 2014 07:07:58 -0700 (PDT)

> to get their act together and "be part of the solution".

You've now changed the scenario. Previously you seemed to be talking about
switching to the new scheme, not running both in parallel.

Since the V2 signatures will be ignored, running them in parallel is
effectively the same as just having V1 signatures to old agents.

> publishing p=reject already does.  They did that.

Again, you're talking about a different strategy now.

> Changing the design of what?

DKIM and subsequently DMARC.

> I wish we could change the design of
> DMARC[1], but I don't think that is going to happen.

Then this entire effort is pointless and we might as well leave it all
to the MLMs to deal with as best they can.

> DMARC is a

Absolutely not. I would have thought this was obvious, but I guess it isn't, so
let me state it plainly: The goal here is to propose changes to DMARC that
improve its interoperability with lists while maintaining the security it
provides.

None of the present proposals make any sense if DMARC agents continue
to only see only V1 signatures.

> is unlikely to occur,

How can there possibly be evidence of anything? We have yet to reach
any sort of consensus on a proposal here. So unless you can cite
a case where a proposal was made to the folks using DMARC along
these lines which was subsequently turned down, I fail to see the
point you're trying to make here.

> it's possible, maybe even quite probable, that
> imposing criticality to serve their own purposes. 

Why would they bother? If they want to do things along those lines, they can
already do them by generating and then requiring a different header field and
there's nothing we can do about it. Indeed, we know for a fact that Google
already does this sort of thing for their own purposes.

For that matter, if someone wants to they can presently require a
DKIM-Signature field be present with various optional fields. And once again
there's nothing we can do about it. Just because DKIM declares some field to be
optional doesn't mean that son-of-DMARC has to. Or that all field values are
acceptable. And so on.

> You describe the

No, the differences are very real. I really don't want to get deep into the
nitty-gritty of X.400, but suffice it to say that there are various
extensbility areas built in to the protocol. The ones defined at the P2
"message" level don't have criticality bits; but one of the ones defined at the
P1 "envelope" level does. And the specifications call for a message to be
outright rejected if there's a criticality bit set on P1 "envelope" extension
that the MTA doesn't understand.

This mechanism caused problems because some vendors added critical extensions
which would then cause other implementations to bounce those messages. Some
cases were probably the result of incompetence, but others seemed more like
attempts to achieve vendor lock-in. (No doubt there was some marketing BS
somewhere to justify what they were doing, but I never saw it.)

There is nothing comparable in Internet mail, and certainly nothing in the
present proposal, for the simple reason that the proposal calls for things
to be ignored that otherwise would be processed.

				Ned

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 26 Jun 2014 03:04:18 +0900

> Again, you're talking about a different strategy now.

Well, one way to look at this is that if the strategy you *thought* I
was talking about involves self-inflicted injury to some participant,
maybe neither that participant nor I are that stupid, and I was
talking about something else.

Not specifying the full scenario was my bad.  We can stop there, at
"my bad", if you like, but it would be more productive if we could
meet halfway, on some bridge between "your good" and "my bad".

 > >  > You're missing the point. We're *changing* the design here so
 > >  > things no longer work this way by associating this with a
 > >  > version bump. And we've already confirmed that a significant
 > >  > number of implementations ignore v=2 signatures.
 > 

That's not *the* design, that's *two* designs you're changing.  DKIM
is "owned" by the IETF, and "we" can change it.

DMARC is not; DMARC is a successful private protocol, and "we" can't
change it.  We can make suggestions that provide sufficient benefits
to the current DMARC participants so that they prefer our proposal to
the one that works for them already.

That's a tall order though.  "Don't fix what ain't broke." 

 > Then this entire effort is pointless

I'm afraid it's going to be unsuccessful, indeed.  That doesn't make
it pointless.  OTOH I'd rather not waste your effort and mine if it is
pointlees.

 > and we might as well leave it all to the MLMs to deal with as best
 > they can.

Well, we MLM devs will deal.  But it's not just us.  There are a bunch
of third parties for whom the workarounds so far are suboptimal.

 > to only see only V1 signatures.

True.  But some of the non-V1 signatures proposed are in new fields.

Why is it a good idea to do an extensible protocol that we don't have
any proposed extensions for?  I grant that if we're going to do that,
a version bump to DKIM-Signature (rather than a new field) is very
plausible.

 > > it's possible, maybe even quite probable, that the big players
 > > will use the possibility of registering values and imposing
 > > criticality to serve their own purposes.
 > 
 > Why would they bother? If they want to do things along those lines,
 > they can already do them by generating and then requiring a
 > different header field and there's nothing we can do about
 > it.

Because if the IETF publishes it, it's a "standard", and the onus is
on them to conform.  If they can conform without conforming, they can
blame everyone else (as Yahoo! and AOL are already doing, albeit
implicitly).  And they can do it explicitly, because they "conform."

 > This [X.400] mechanism caused problems because some vendors added
 > critical extensions which would then cause other implementations to
 > bounce those messages.

Sounds like "p=reject" to me.  More precisely, in the "p=reject"
environment, ignoring things is no longer "fail-safe", it's
"fail-mail-lost".  A critical extension must be handled properly, or
the signature doesn't validate ... and the message bounces.

Steve

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 Jun 2014 11:41:34 -0700 (PDT)

> the one that works for them already.

In other words, if may be difficult but we can change it.

> any proposed extensions for?

First, the protocol is already extensible, just not in the right way for this
case. 

Second, what do you think the "non-V1 signatures in new fields" are if
they aren't extensions?

> I grant that if we're going to do that,

> implicitly).  And they can do it explicitly, because they "conform."

You're confusing the definition of an extensibility mechanism with its use. We
specify extensibility mechanisms all the time without there being any
implication that someone using them is creating any sort of standard. Indeed,
we could, as part of this mechanism,  include additional tagging to make it
clear whether or not a given set of tags are standardized or not.

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 have described the issues that have
occurred, as well as why that won't happen here.)

> the signature doesn't validate ... and the message bounces.

I have previously explained why the contexts aren't remotely comparable, but
let's suppose for a moment that they are. "p=reject" was in no way dependent on
any kind of extension to DKIM. Indeed, the main motivation behind extending
DKIM is that DKIM gives us no way to specify what a signature is for, which
makes it impossible to sign something twice with different grades of signature
while making sure the weaker one isn't used for the wrong purpose.

Although I don't agree with it and think it's gone one layer of abstraction too
far, I accept the design decision that having a means to specify the intended
purpose of a given signature in the signature itself is the wrong approach.
Which means the only alternative is to extend the signature semantics one way
or the other. 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.

				Ned

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 26 Jun 2014 14:20:47 +0900

> First, the protocol is already extensible, just not in the right way for this

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

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.

---

From: Ned Freed <[email-masked]>
Date: Thu, 26 Jun 2014 00:46:32 -0700 (PDT)

> 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*.

> 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.

> 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?

> insufficient evidence to lead me to the same conclusion in your

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.

> DKIM-signature-based solutions.

That's the general problem I'm talking about. So it seems we agree
it can be solved cleanly.

> well, and those leading to conflicting requirements.

In which case you define new critical tags to specify those semantics.

> As soon as you

Of course it's necessary to properly design and specify future extensions. Any
concievable mechanism carries with it the potential for misuse.

> 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