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

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Mar 2006 15:09:36 +0000

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
generation "at home" and e.g. to distribute private keys to delegates
on tamper resistent devices (e.g. USB sticks or whatever), so its
hard to justify the "should".  Same issue shows up with the signed
public keys - signed by whom, verified how, etc. are all questions
that would need to be answered before such a "should" (even lower
case) would be appropriate.

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.

Stephen.

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

---

From: Mark Delany <[email-masked]>
Date: Thu, 9 Mar 2006 15:26:35 +0000

> 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?

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Mar 2006 15:53:52 +0000

Mark Delany wrote:
> non-normative suggestions on possible strategies. 

Yes. Hopefully the latter, but I wasn't sure.

 > I don't see rfc2821

Well from memory s/mime and pgp don't but then they don't have the
delegation aspect. Nearest thing to this is maybe the proxy-cert
stuff that the Grid folks did, but they distribute short-lived private
keys in-band so have to care more. PKIX does give us many many ways
to do this (CMP and CMC both specify a slew of options).

Anyway, if anything that's an issue for base, not threats. (Is it
worth raising one so we discus it in Dallas?)

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 09 Mar 2006 22:34:46 -0800

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Mar 2006 07:36:23 +0000

Jim Fenton wrote:
> Mark Delany wrote:
>> On Thu, Mar 09, 2006 at 03:09:36PM +0000, Stephen Farrell allegedly wrote: >

> Sound better, and less normative-leaning?

Works perfectly for me.
S.

---

From: Mark Delany <[email-masked]>
Date: Fri, 10 Mar 2006 14:24:04 +0000

> A related threat is the exploitation of weaknesses in the delegation

Ahh. Now I see what that section was getting at. The revised text
looks good to me.

Mark.