Subject: RE: [ietf-dkim] x= lets senders expire responsibility

From: <[email-masked]>
Date: Fri, 14 Apr 2006 13:53:57 -0400

I suspect in the real sysadmin world changing keys every week probably
isn't going to happen :-)

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Friday, April 14, 2006 1:32 PM
To: Douglas Otis
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-DKIM" <[email-masked]>
Sent: Friday, April 14, 2006 12:26 PM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility

> One simple solution would be to change the recommendations and ensure
> a reasonable period for accessing keys to enable protections over
> IMAP and POP transit.  A recommendation might be changed to weeks
> rather than days.
>
> ...
>
> A faster polling rate for an MUA is a not a solution. : (
>

Doug,  the current recommendation is 7 days.  That means that at a
minimum
the polling rate for your MUA needs to be 6.9 days or less if you don't
want
to experience problems.  Right?

Even if the recommended key retention time is increased to 2 weeks, your
MUA
minimum polling rate is now 1.9 weeks or less, and so on.

So while the higher retention time is better for the MUA to not miss
revoked
keys,  you will always have the same timing issue with the offline MUA.

Right?

---
Hector

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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Apr 2006 11:04:46 -0700

> isn't going to happen :-)

Given the intended use of DKIM and given the current state of DNS administrative 
tools, what do folks think *is* a realistic expectation (and recommendation) for 
the lifespan of a key, for a typical email operation?

In other words, given the pragmatics, how often is reasonable an appropriate for 
changing keys?

d/
-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Apr 2006 11:10:56 -0700

On Apr 14, 2006, at 11:04 AM, Dave Crocker wrote:

> Given the intended use of DKIM and given the current state of DNS  
> administrative tools, what do folks think *is* a realistic  
> expectation (and recommendation) for the lifespan of a key, for a  
> typical email operation?
>
> In other words, given the pragmatics, how often is reasonable an  
> appropriate for changing keys?

I expect to see four varieties.

1) Never changes

2) Never changes except when someone realizes they've lost or
leaked the private key.

3) Changed monthly.

4) Cycled on a regular hourly or daily schedule with automatically
generated keys and expiration of DNS records for old keys running
on a custom stunt DNS server.

And I'd expect the vast majority to be the first or the last. Of those,
mostly the first.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Apr 2006 11:21:59 -0700

Dave Crocker wrote:

> administrative tools, what do folks think *is* a realistic expectation 
> (and recommendation) for the lifespan of a key, for a typical email 
> operation?
>

I don't want to put words into Arvel's mouth, but my read of his users 
experience
is that you struggle to get the keys into the DNS once and hope that you 
never have
to struggle with it again. I think his base is mostly small/medium 
business.

For larger business and maybe ISP's even, our anecdotal experience at 
Cisco is
that our messaging and DNS folks don't have mich to do with one another 
(changing
mx records is not a ordinary event). Thus to achieve key rollover, you'd 
need
to create linkages between the groups and their software that didn't 
exist before.
Which is to say, a very slow process for the motivated, and a 
non-process for
the unmotivated. Maybe SPF has helped here, but I doubt it.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Apr 2006 13:19:23 -0500

> appropriate for changing keys?

I'm just going to be honest and say that I have NEVER changed my key 
since we started signing with DK over 14 months ago.  I think I should 
also throw out that our customers won't regularly change their keys 
either (unless I can figure an automated way to do it for them).  Unless 
the key has been compromised, why bother with changing it at all?  I'm 
sure I have much to learn here and am about to learn it :)

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Apr 2006 11:28:04 -0700

> on a custom stunt DNS server.

To the extent that the working group might wish to specify normative behavior, I 
suspect that Choice #1 should be a MUST NOT and probably the same for #2.

Is #3 a comfortable choice, in terms of balance and effectiveness?  Would a 
different, simple choice be better?

#4 probably is some sort of ideal, but not reasonable to expect or press form.

d/
-- 

Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Apr 2006 13:35:09 -0500

> To the extent that the working group might wish to specify normative
 > behavior, I suspect that Choice #1 should be a MUST NOT and probably
 > the same for #2.

I hope the spec doesn't get into putting requirements like that in 
place.  It would be a burden on deploying DKIM in small operations that 
depend on others for DNS management.

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Apr 2006 11:41:45 -0700

Dave Crocker wrote:

> Is #3 a comfortable choice, in terms of balance and effectiveness?  
> Would a different, simple choice be better?
>

Can I suggest that this is a better topic for the BCP? Making normative 
requirements
on operational issues is usually pushing on string in the best 
circumstances.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Apr 2006 19:58:02 +0100

Hi Arvel,

> sure I have much to learn here and am about to learn it :)

There are cryptographic reasons why you don't want to keep using
the same key forever, but I don't believe that we need worry too
much about that here (anyone done the math to see how many
signatures before its a concern?).

More practical things that you do need to consider include:

- If using s/w crypto, then everyone who can login or run code on
   that box can potentially grab the private key, so you need to
   figure out how much risk that represents and probably try to
   change keys so that you reduce the risk to what you consider is
   an acceptable level.

- Decommissioned equipment (s/w or even h/w crypto) is a potential
   source of key leakage, if you do this often, particularly with
   s/w crypto you should replace and revoke, because no matter how
   hard you try there may be key bits exposed on the old kit. If
   you clone boxes (and keys) this all gets worse of course.

But basically DKIM is no different from secure web servers in terms
of private key handling, so there's plenty of experience out there.
One difference might be that annual certificate expiry tends to
cause key replacement in the SSL/TLS case.

Stephen.

---

From: John Levine <[email-masked]>
Date: 14 Apr 2006 21:08:37 -0000

>different, simple choice be better?

I have to agree with Mike (alert the media!) that key management belongs
in a BCP, not in the spec.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 14 Apr 2006 23:34:29 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: <[email-masked]>

> I don't want to put words into Arvel's mouth, but my read of
> his users experience is that you struggle to get the keys into
> the DNS once and hope that you never have to struggle with it
> again. I think his base is mostly small/medium business.

We saw basically the same issue with SPF.  Our customers are spread from
hobbiest, SOHO, small/med/corporate to ISPs.

Overall, early slow inertia for adoption boiled down to:

  - Not understanding why it was needed,
    they knew it for "AVS" but didn't understand how/why it worked.

  - Not having access to DNS servers to explore, even if internal.

  - ISP/ESP not having web-based TXT record management support.

Also, very important, for our package, 99.999% of it is GUI configurable.
Without our SSL GUI Wizard, it would of slowed down adoption. I recall
wanting to also give sysops DNS record management for SPF.  But there were
DNS server technical issues in the area of updates so we left this to
documentation for now.   No doubt, vendors that help in the management will
help accelerate adoption.

No doubt, I think DKIM is alittle more complex than an SPF.  I think DKIM
key management tools is more critical to help accelerate exploration and
adoption.

> Cisco is that our messaging and DNS folks don't have mich to do
> with one another (changing mx records is not a ordinary event). Thus
> to achieve key rollover, you'd need to create linkages between the
> groups and their software that didn't exist before. Which is to say,
> a very slow process for the motivated, and a non-process for

It has help highlight the requirement. I can't name them all, but no doubt
ISP/ESP did who didn't have TXT support at first in their web-based
management tools, did add TXT support to help support SPF customers.

For DKIM, ISP/ESP who begin to offer signing services, free, fee-based or
otherwise will help the process.  It will also depend a lot on vendors
and/or 3rd party developers making this near-complex implementation easier.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 15 Apr 2006 15:54:59 -0400

From: <[email-masked]>

> I suspect in the real sysadmin world changing keys every week
> probably isn't going to happen :-)

You probably mean "isn't going to happen too often"  :-)

The issue is the "period" when there is concurrency of keys, the rollover
time.

So even if you have a key for over a year, the day you do decide to switch,
how long do you keep the old one?  The current minimum recommendation is
seven (7) days. I have no problem changing that two weeks.

In my book, this is not a big deal because there isn't going to be any
solution to the idea of some time-shifted, belated, delayed verifier, with
the extreme case of a vacation user not picking up his mail on a regular
basis.  This is especially the case, when it has no help from the backend.
The MUA can pick up DKIM signed messages from different places, each with
their own rollover retention periods.  So in my book, its just the nature of
the beast for the MUA.

Also consider this, the USER who installs a MUA DKIM-ready system or DKIM
plug-in, will probably now get vendor instructions that says:

    "Installing this PLUG-IN requires your MUA to do mail pickups on
     a regular basis.  Delaying mail pickups over extended periods
     (Weeks), can cause false positives with DKIM signed messages."

Or something like this.  The vendor is aware of the situation and they will
make sure the USER will be aware of the situation as well.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 16 Apr 2006 11:08:46 -0400

----- Original Message -----
From: "John Levine" [email-masked]

> I have to agree with Mike (alert the media!) that key
> management belongs in a BCP, not in the spec.

Could there be a generalize "BCP" that can be part of a DKIM-BASE and covers
a basic methodology?   I would like to see atleast a "summary" in the
DKIM-BASE since it is a very important consideration to help the adoption
process.

Maybe a section that consolidates all the thoughts mentioned throughout the
DKIM-BASE document, including hindsights about possible implementation
considerations would help.  Here is a basic outline.  Maybe it can serve as
input for some administrator to write this BCP.

Extracted from Current Proposal

x.0) Key Retention and Rollover Stategies

  x.1) Selectors/Keys

    a) One key per selector  (section 3.1)

  x.2) Key Revocation

    a) Concurrent selectors during transition (section 3.1)
    b) Minimum seven (7) day (section 5.2)
    c) Empty p= data for revocation (section 3.6.1)

  x.3) Signature Expiration

    a) No x= tag, no expiration  (section 3.6.1)
    b) Expiration promotes invalid signature (section 3.6.1)
    c) No verification required (not implicitly stated)

  x.4) Explicit Classification Statements

    a) Expiration forces invalid signature. (section 3.6.1)
    b) Key Revocation forces failed verification. (section 6.2)

Implicitly and Explicitly Extracted Problems/Objectives

  x.5) Security needs to revoke keys

    a) for invalidating signature.
    b) (NOT?) for message expirations.
    c) without losing original validity.
    d) without removing domain responsibility.
    e) without destroying domain reputation.

  x.6) Time-shifted Verifications Issues

    a) Abnormal Transport Delivery Times
    b) Post Transport, Delay Verification
    c) Offline MUAs

---

From: Douglas Otis <[email-masked]>
Date: Sun, 16 Apr 2006 13:44:06 -0700

>      (Weeks), can cause false positives with DKIM signed messages."

By not blanking the public portion of the key, a key status indication
could overcome problems related to prematurely causing messages not to
verify at the MUA.  

Special actions desired by the sender will likely want to occur at the
MDA and not the MUA with respect to the key changing status.  Add a key
parameter that indicates a key has been retired.  This would allow
continued processing of received messages prior to MUA verification.  

This would permit a differentiation between handling related to messages
with revoked keys, versus those with retired keys.  Perhaps in the
revoked key case, the message would be silently discarded, rather than
rejected.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 17 Apr 2006 14:16:31 -0700

Michael Thomas wrote:
> that our messaging and DNS folks don't have mich to do with one
> another (changing
> mx records is not a ordinary event). Thus to achieve key rollover,
> you'd need
This is true, but that's part of the benefit of putting the keys in the
_domainkey subdomain:  it makes it possible, at least, for the messaging
folks to bug the DNS folks once for an NS delegation and then manage the
rest themselves.  Assuming the DNS folks will actually give them the NS
delegation, of course.  And our anecdotal experience at Cisco is that
they will.

-Jim