ietf-dkim
[Top] [All Lists]

[ietf-dkim] Email upgrade history

2007-02-25 13:11:46


Michael Thomas wrote:
   If we allow multiple algorthims, and not all the
algorithms are the the "MUST implement" level, this attack is feasible.
...
At this point, all we have is MUST implements. Considering there is
no opportunity for negotiation with mail, MAY/SHOULD implement
algorithms seems like a pretty bad idea altogether. So is this still a real
problem for DKIM?


It is probably worth making sure that we are all in synch about some relatively basic email protocol points:

1. SMTP permits negotiation. That's hop-by-hop, rather than end-to-end, which is what I assume you meant.

2. It turns out that there is also a newly-defined capability for negotiation between originator and recipient, but it is neither broadly adopted nor useful for DKIM-related issues, IMO.

3. Email has been doing upgrades for a long time. New header fields. MIME. HTML. Text line-wrapping. And so on. None of these has used any sort of policy publication mechanism. All have had massive, long-term success.


So,

As much as upgrades might be made easier by being able to query a record published by the signer, there is no track-record of requiring such a thing, for email or, I believe, any other Internet protocol. This means that we need to be extremely clear about the reason that any such a record is absolutely essential.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>