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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Apr 2006 11:00:42 -0700

> From: william(at)elan.net [mailto:[email-masked]] 

> On Wed, 12 Apr 2006, Hallam-Baker, Phillip wrote:
> 
> > I disagree.
> >
> > I think the semantics are 'don't count on being able to verify this 
> > message after this date'.
> 
> This is signer's policy information. From what I've seen so 
> far its largely the same set of people who are against this 
> as those against what you call SSP. I'm afraid this maybe a 
> light prelude to what you'll see in SSP debates....

It is cetainly the case that a SSP might want to make a statement of the
form 'signatures will be good for at least 2 weeks from the date of
signing'. I think that a case can be made for putting the info in the
signature itself as well. That way the verifier can decide to skip attempts
to obtain the key if that is its policy.

As far as I am concerned definition of a security policy for an Internet
protocol has not been serously tried to date (except for MARID). The lack of
security policy is on of the main reasons that S/MIME and PGP are not
suitable for the task at hand. I have yet to hear a single covincing
argument against making the attempt. The proper time for such arguments to
be made is after the initial spec has reached PROPOSED standard and there is
adequate deployment experience to rely on.

Lets do our job first and then discuss these issues.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Fri, 14 Apr 2006 14:43:47 -0400

Mike said
*************
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 our situation, so I sidle over to the DNS folks to get a swag
and right after

"WHY THE H*** ARE YOU DOING THIS IN DNS? DO IT AT THE MTA FER XXXXXSAKE"
The answer was quarterly is the minimum time they would be willing to
change keys
.
Thanks,
 
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 Michael Thomas
Sent: Friday, April 14, 2006 2:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-dkim] x= lets senders expire responsibility

Dave Crocker wrote:

>
>
> [email-masked] wrote:
>
>> I suspect in the real sysadmin world changing keys every week
probably
>> 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?

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