> >I do not understand this predilection for trying to change the DKIM base
> >engine. It doesn't need it.
> Actually, I claim that a version bump is the approach least likely to
> break existing clients.
> >I also don't understand the construct of 'special handling', never mind
> >not liking the idea of it, especially since it explicitly creates the
> >complexity of "depends on the header field".
> I think we agree that the goal here is to have a weak signature that
> verifiers disregard unless it's associated with a delegated signature.
> Your plan, as I understand it, was that verifiers will ignore a
> signature that is too weak. One might argue clients that accept weak
> signatures are already broken, but in that case there are an awful lot
> of broken clients, starting with spamassassin. (I just checked.)
Out of curiousity, did you try having two signatures in various different
orders and combinations of validity?
Mind you, even if this leads to a way of structuring these things
that "works" for the current crop of clients, I would not be inclined to
trust it. I'm just curious.
> Until now there's been no reason other than playing games to use weak
> signatures, so in practice it hasn't mattered. Now it does, so
> clients have to change their code to check for "too weak", probably in
> inconsistent ways, to check for l= and what headers are signed and so
> forth.
Agreed. Like it or not, this calls for, let's call it a "clarification"
of existing DKIM semantics. And to do that you either bump the version
or overload some other existing field in the protocol.
> Murray's trick, add a new canonicalization that's only valid if
> there's a paired signature, many not require a version bump, but to be
> useful it does require a change to the verifier library interfaces.
Six of one, half a dozen of the other.
> Libraries and clients are not upgraded in sync, so there will be old
> clients calling upgraded libraries. The libraries can't just accept
> the new canon and return "valid", since old clients won't know to look
> for the paired signature. They can't return "conditionally valid",
> since clients won't know what to do with it. So the libraries will
> need a new entry point, or at least a new option, for the client to
> say that it understands a conditionally valid result. A few moments
> thought should confirm that's semantically the same as an option for a
> client to say it understands v2 signatures, just kludgier.
Exactly.
> With respect to Stephen's concern about libraries knowing when to
> construct v1 or v2 signatures, really, that's no big deal. We've been
> doing that sort of stuff for version bumps since approximately
> forever, and it's a nit compared to the other stuff it'll have to do
> to interpret the conditional signatures.
> It also occurs to me that there are all sorts of ways that a
> conditionally valid signature would be useful. For example:
> * valid if this DNS lookup resolves, for per-signature revocation
> * valid if the body has this S/MIME signature, to allow for list
> software that reformats the message but keeps the signed body part
> (mailman and mj2, for example) or that resigns with its own S/MIME
> signature (sympa)
> * valid if the body has this PGP signature (mailman's working on it)
> Some of these can be done with kludges, but most can't.
Exactly why I think that as long as we're bumping the version, building in some
additional extensibility seems like a really good idea. The only question
is how much and in what form.
Ned
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
