[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and
dotis at mail-abuse.org
Mon Feb 26 07:42:42 PST 2007
On Feb 26, 2007, at 7:19 AM, Michael Thomas wrote:
> I'm still not seeing what the problem is with things as they stand
The DKIM WG would not have not provided a reasonable solution if
there were known easily exploitable weaknesses. Avoiding a downgrade
attack considers what might be needed to accommodate a transition in
algorithms. Currently, there are no reasonable mechanism for doing so.
> We've already been through a transition with sha1 and sha256. The
> solution was to make both signatures in the transition and set the
> h=sha1|sha256; in the selector.
Those changes are possible during the initial definition of an
algorithm. Once widely deployed and heavily depended upon, such
changes without a transition scheme would be impossible to achieve.
> All you do when you're ready to completely transition is only sign
> with the new algorithm and set h=sha256; in the selector.
There are many algorithms involved with DKIM. Canonicalization,
hash, crypto, header strategies, signature associations and more must
be considered representing possible weaknesses which might require
some future change. Few can predict what might become problematic.
> This is exactly the kind of case we wanted to get right for -base
> and as far as I can tell it worked exactly as intended.
No one is claiming that base is broken from a security standpoint,
but it might be in the future. When defining signer policy, a
critical aspect relates to what is being used, and what has been
deprecated. The concept of deprecated _is_ broken in the base draft.
More information about the ietf-dkim