more 1368 discussion (Re: [ietf-dkim] Re: 1368 straw-poll :)

[Michael Thomas]

Hallam-Baker, Phillip wrote:
>> [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.

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