ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

2009-06-01 17:41:23
Dave CROCKER:
Let's make sure everyone is in synch about what is being proposed:

      The suggestion is to drop a tag from the *DNS record*, /not/
      from the *DKIM-Signature* header field.

What is the benefit of having the DNS record list possible
algorithms?

A protocol like this has specification language that says "everyone
MUST support algorithm P and MAY support other algorithms.  When
the data arrive, they contain an indication of what algorithm has
been used for this data."

The "MUST" ensure basic interoperability.  The "MAY" permits
extensibility, based on mutual agreement.  Requirements for
supported algorithms can be extended by enhanced specifications
"MUST support algorithms P, Q and R".

It does not really matter how many algorithms are referenced in
the specification or how many might be in the future.  The list
is in the specification.  And the arriving data declare which
algorithm has been used this time.

But what utility is there in having a signer list in an external
record the algorithms they might choose to use?  Absent this
justification, there is not "when" for needing the feature.

As I recall, the argument in favor of this tag in the DNS was a
security concern that a message might arrive with an "unauthorized"
algorithm.  For myself, I was never quite clear what actual threat
this represented, in terms of feasibility, likelihood or severity.

Reasons to drop this feature from the DNS record:

1) It assumes that the domain owner is giving the private key to
"rogue" signers that are willing to use "unauthorized" algorithms.

2) It requests that receivers ignore signatures from "rogue" signers
when they use these "unauthorized" algorithms.

3) It won't stop "rogue" signers from sending mail that is signed
with an "unauthorized" algorithm anyway.

        Wietse
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html