[ietf-dkim] Re: 1368 straw-poll :

[Hallam-Baker, Phillip]

> [mailto:ietf-dkim-bounces at mipassoc.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.