Folks,
G'day.
I've now caught up on the list activity and am sending my combined
comments in a single posting, especially since I think there's really a
single organizing issue that's being missed...
On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote:
> Well, for Author Domains publishing "p=reject", we can certainly
> confuse the issue dramatically. Change the protocol to advocate
> "silent discard"
Question to the group: Does silent discard help? Or rather, do we have
any indication that noisy "p=reject" does or can hurt?
On 6/15/2014 9:43 AM, Murray S. Kucherawy wrote:
> On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker <dcroc...@gmail.com>:
> What I was suggesting was merely registering a new canonicalization
> algorithm. Legacy DKIM implementations won't understand it. New
> ones (presumably also modified to know about DMARC) will.
...
>
> The reason I don't like this approach -- assuming I am not missing
> something from this idea -- is because then we are, directly or not,
> tying verification semantics outside of DKIM to a canonicalization.
One way or the other, the different approaches are trying to trick
legacy receivers into being unable to process the weaker signature. As
the cliche goes, we are merely haggling price.
However price matters; we should have a good reason for choosing one
trick over another. Still I think we shouldn't trick ourselves into
believing this game is anything other than producing a hack.
On 6/15/2014 10:00 AM, John Levine wrote:
>> 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.
The premise is that a version number change will be noticed by a legacy
DKIM engine.
While of course it ought to be noticed, do we have evidence that it
reliably is?
There's some history with version numbers not working for Internet
protocols. (I get some perverse enjoyment out of noticing that IPv6
requires a different ethertype value, rather than just relying on the IP
version field...)
>> 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.)
That does not make the issue any less fundamental.
The DKIM specification leaves it to the receive-side evaluator to decide
whether "enough" of a message was covered and whether the signature was
"sufficiently" strong. If engines are currently ignoring this issue, we
have a deeper problem, IMO, and should focus on fixing that, rather than
treating it as an acceptable given.
> Until now there's been no reason other than playing games to use weak
> signatures, so in practice it hasn't mattered.
Right. Some problems don't surface right away. That does not mean we
should ignore these sorts of underlying problems and just work around them.
> 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.
It's definitely a paradigm change.
Arguably the change is 'above' DKIM, in the sense that the core DKIM
engine remains unchanged, but rather it is the interpretation of the
result for a DKIM evaluation that can be different.
Merely validating a signature is /never/ supposed to give a message an
automatic pass. Rather, the validation is supposed to be fed into an
analysis engine that considers a variety of factors.
Adding a requirement that one validation needs to be accompanied by a
particular other valid signature is just such an additional factor.
In other words, the changes being discussed here are really
in DKIM usage policy and not DKIM signing/validating.
> 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.
Please point to details on the long history of successfully doing
version bumps in Internet protocols. I'm not aware of it.
I see that http has done it, though I don't know how it is used or how
useful it has been. But I haven't noticed the construct being generally
useful for other protocols. Certainly not for IP... And note that the
rest of the email specs haven't used them.
> It also occurs to me that there are all sorts of ways that a
> conditionally valid signature would be useful. For example:
The signature is not "conditionally valid". The signature validates or
it doesn't. Binary choice. That a signature is what we are calling
weak does not make it more or less valid.
What is conditional is the /use/ of the validation, just as is supposed
to already apply for validated DKIM d= values.
So the enhancement here concerns a new layer that
specifies DKIM usage policies, not changes to the
existing signing/validating engine.
This does invite the basic and continuing need to worry about how things
will be processed by legacy engines that don't know about the
enhancements. However we need to be careful in making assumptions about
this rather than empirical information.
On 6/15/2014 11:58 AM, ned+dm...@mrochek.com wrote:
>> 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.
I understand the premise here, and agree it's reasonable. What I don't
know is whether it is valid. That is, we have a presumption of a
problem but I haven't noticed documentation that the problem is real and
serious, to justify making a change to the basic DKIM platform.
More generally, the IETF has often done BCP-ish documents that clarify
usage issues -- such as "watch out for 'weak' signatures" without
changing protocol version numbers.
>> 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.
Which is why I'm classing this as adding a policy engine on top of the
(stable and unchanging) DKIM signing and validation engine.
For reference, I note that some other postings on the list have been
making a similar distinction between validation and policy. However
they do not seem to have gotten traction.
On 6/20/2014 7:42 AM, John R Levine wrote:>>> 4. How does the sending
MTA know when to stamp this v=2 DKIM
>>> header? Presumably, it would need to have a list of known
>>> forwarders stored somewhere?
>
> That seems likely,
And this underscores just how strange the current discussions are, since
a list like that doesn't scale.
On 6/19/2014 2:46 PM, Ned Freed wrote:
> So, are we going to create a new header field every time we come up
> with some new required semantic we want to attach to a DKIM
> signature?
...
> Why don't we fix the extensibility problem instead?
+1
Anyhow and FWIW...
As we worry about 'suddenly' having to worry about getting receivers to
be careful if they receive a 'weak' signature, let's consider the
suddenness in the context of the literally overnight, rapid expansion of
DMARC use into generalized mass-market scenarios.
By comparison, anything we are talking about doing here is at glacial
speeds.
That is, it is arguably quite easy to get DKIM receivers to start paying
attention to signature strength, without anything other than a public
awareness campaign, and certainly not needing anything as extreme as a
version number change to an engine that is not actually changing...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
