ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: threats-01 over prescriptive about key delegation

2006-03-10 00:13:38
Mark Delany wrote:
On Thu, Mar 09, 2006 at 03:09:36PM +0000, Stephen Farrell allegedly wrote:
  
4.1.2 says that delegates should generate key pairs and should send
signed public keys to the domain owner. There are a couple of problems
with this, if its really meant seriously.

Firstly, some domains might quite reasonably decide to do key
    

  
Second issue is that this document isn't the right one to specify
such solutions.

However, there's an easy fix: s/should/could/ twice and
s/minimize/reduce/ makes it all ok IMO.
    

Right. One even wonders whether this is specification text or simply
non-normative suggestions on possible strategies. I don't see rfc2821
offering the mechanics on installing an MTA. Do other pub-key related
specs delve into deployment?
  
I think what happened here is that in writing this section I fell "out
of character" for a threats document.  It's definitely not intended to
be normative; nothing here is because threat analyses are
informational.  What I meant to say was something more like:

A related threat is the exploitation of weaknesses in the delegation
process itself.  This threat can be mitigated through the use of
standard precautions against the theft of private keys and the
falsification of public keys in transit.  For example, the exposure to
theft can be minimized if the delegate generates the keypair to be used,
and sends the public key to the domain owner.  The exposure to
falsification (substitution of a different public key) can be reduced if
this transmission is signed by the delegate and verified by the domain
owner.

Sound better, and less normative-leaning?

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