Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael Thomas
Well, I have one small quibble in that I don't understand
what the actual problem is. While that's not a huge problem
in the global scope of things, I do need to understand this
enough to transcribe the outcome. In particular, I haven't
seen any clarification as to why the algorithm bindings in
-base are not sufficient to cover this attack; having -base
already solve the problem is the best outcome, right?
The policy language needs to be expressive enough to be able to reference them,
that is all.
If you only support algorithm A then your policy and key records would be:
_dkim_policy.example.com TXT "DKIM"
keya._dkim_keys.example.com TXT "alg=RSASHA1 v=32q4qtiuhwq"
If you always use algorithm A but also support B then you would have:
_dkim_policy.example.com TXT "DKIM=a._dkim_keys.example.com"
k1.a._dkim_keys.example.com TXT "alg=RSASHA1 v=32q4qtiuhwq"
k1.b._dkim_keys.example.com TXT "alg=RSASHA256 v=aqjqhj32qafoiju4qtiuhwq"
If you always use algorithm A and B then you would have:
_dkim_policy.example.com TXT
"DKIM=a._dkim_keys.example.com DKIM=b._dkim_keys.example.com"
Just to be clear here: nobody is arguing for the ability to specify the
algorithm in the policy record or anything like it. There lies the road to
madness. We do all of that using base.
Also the most likely near term change would be a new cannonicalization
algorithm rather than a digest.
But that's exactly what we have right now with -base and -ssp. The
algorithms can already be constrained in the selectors themselves. For
policy, it should be sufficient to say that "I sign everything" means
that the signatures comply with the -base definition of "verified" which
already includes which algorithms are acceptable in the selector itself.
Is what is at issue is that it's not sufficiently clear in the
requirements of what constitutes a "valid DKIM signature" because
we don't enumerate that the h= and a= tags in the selector be
obeyed by the signer and/or receiver?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html