Mailing List Archive

Re: Rotating secrets
On Sat, Feb 21, 2004 at 01:52:13AM +0000, Mark wrote:
> We have been talking about the SRS secret of late. I am many things, but not
> a cryptographic hero. :) So, feel free to correct my thinking. But I was
> wondering the following:
>
> Let's say "MaxAge" is set at 4 days. If the secret is to be changed, at
> intervals, would that not imply that ALL returned SRS addresses, from that
> moment on, are immediately invalid? Or do they remain valid until their
> initial expiration time? In concreto, would a "reverse ()" on an address
> with the old secret still be valid?

I can't comment on any specific implementation of SRS, but in general, if
you are changing the secret on a system like this you need a parallel
running period where both old and new secrets are accepted.

e.g. if you are stamping messages with a 7-day expiry, and you change the
secret from X to Y for outgoing messages, then for the next 7 days you need
to accept incoming bounces signed with either X or Y. After that you can
forget about X.

> If not, then there is, of course, a slight problem, in that changing the
> secret effectively nullifies the expiration date on all addresses that were
> already sent out.

Absolutely.

> Though I have no immediate need to change the secret (why
> would I?), still, I wonder how to deal with this should it become necessary.

Yep. Changing it when a sysadmin who knows the secret has left the company,
or once a year anyway to be on the safe side, would be a wise precaution.

Regards,

Brian.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Rotating secrets [ In reply to ]
On Sat, 21 Feb 2004, Mark wrote:

> We have been talking about the SRS secret of late. I am many things, but not
> a cryptographic hero. :) So, feel free to correct my thinking. But I was
> wondering the following:
>
> Let's say "MaxAge" is set at 4 days. If the secret is to be changed, at
> intervals, would that not imply that ALL returned SRS addresses, from that
> moment on, are immediately invalid? Or do they remain valid until their
> initial expiration time? In concreto, would a "reverse ()" on an address
> with the old secret still be valid? The README says, "Validates all
> cryptographic and timestamp information."

The implementation permits multiple secrets to be stored, and will check
each in turn until one is successful, or all fail. This permits
administrators to change secrets, as long as they keep the old secret(s)
as secondary secret(s) for the length of the timestamp window (e.g. 4
days).

This is an implementation issue, rather than a protocol issue, and I
currently speak only for the Perl implementation. I think the C
implementation does not yet provide this functionality.

I hope this (at least partially) settles your concerns.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Rotating secrets [ In reply to ]
From: <spf@anarres.org>
To: "Mark" <admin@asarian-host.net>
Cc: "SRS-Discuss Forum" <srs-discuss@v2.listbox.com>
Sent: Sunday, February 22, 2004 7:36 PM
Subject: Re: [srs-discuss] Rotating secrets

> On Sat, 21 Feb 2004, Mark wrote:
>
> > We have been talking about the SRS secret of late. I am many things, but
> > not a cryptographic hero. :) So, feel free to correct my thinking. But I
> > was wondering the following:
> >
> > Let's say "MaxAge" is set at 4 days. If the secret is to be changed, at
> > intervals, would that not imply that ALL returned SRS addresses, from
> > that
> > moment on, are immediately invalid? Or do they remain valid until their
> > initial expiration time? In concreto, would a "reverse ()" on an address
> > with the old secret still be valid? The README says, "Validates all
> > cryptographic and timestamp information."
>
> The implementation permits multiple secrets to be stored, and will check
> each in turn until one is successful, or all fail. This permits
> administrators to change secrets, as long as they keep the old secret(s)
> as secondary secret(s) for the length of the timestamp window (e.g. 4
> days).

Excellent! :)

> I hope this (at least partially) settles your concerns.

This is exactly what I wanted to hear. I knew you had thought of this
somehow. :) I will add a secret now. Great!

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com