Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a
signature of type B"
Now consider a recipient that only supports verification of
signature type A.
Consider the following attack:
Bogus message with signature of type B.
This message is consistent with policy X, it is not
consistent with policy Y. This means that if our policy
language can only express policy X it will not be possible to
tell the recipient the information it needs to know in order
to determine that the message is bogus.
Huh? The recipient doesn't support signature type B and will
therefore not consider the message signed.
No, that does not work. The issue here is whether there is a policy violation
or not.
From the verifier perspective: there is no policy violation. They've
just gotten an unsigned message and treat that however they want.
(I suspect we're talking at cross purposes?)
If you treat messages signed with an algorithm you do not understand as policy
violations you are going to reject legitimate messages.
Since I don't agree that the premise applies, the rest is moot.
The behavior you describe must be prohibited with a MUST NOT if there is to be
any chance of ever deploying an upgraded algorithm. Otherwise the minute
someone starts signing with just DSS their messages will be tagged as policy
violations.
I don't agree with either the conclusion or the language.
It is always possible to forge messages. Our job here is to
make it relatively easy to do a good job verifying real ones.
That was base. We are now onto policy.
The goal of policy is to allow conclusions to be drawn from the absence of a
verifiable signature.
Sure. And we're discussing which conclusions are required.
And we disagree about that, but that's ok.
The output of the DKIM base is :
NO-VALID-SIG - There was no signature (NO-SIG) OR
There was a signature but its broken (SIG-BROKE) OR
There was a signature that is not (NO-SUPPORT) supported
VALID-SIG - There was an acceptable signature that verified correctly
(ACCEPT-SIG)
There was a deprecated signature that verified correctly
(DEPREC-SIG)
Is *any* of that in base? I don't think so. Base actually only talks
about PERMFAIL and TEMPFAIL, so I think you're making assumptions
about how you'd implement - they may be reasonable assumptions, but
equally there may be other, conflicting, but just as reasonable, ways
to do things.
The outcome of DKIM + Policy is different, it is:
COMPLIANT - The message is in compliance with the specified policy
NOT-COMPLIANT - The message is not in compliance with the specified policy
I think we could argue there, but you're delving into design now, not
requirements IMO.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html