Subject: [ietf-dkim] multiple keys under same selector+domain?

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Apr 2006 13:32:25 -0700

Folks,

I did a quick scan of -core and did not find this issue dealt with:

When moving to a new key for a domain, may the same selector be used, or is the 
signer required to use a different selector?

Stated differently:  Is it true that a given selector+domain DNS lookup name 
will produce at most one key, forever?

I think some folks believe that it might produce a different key, over time, and 
I'd like us to be clear about whether it can do that.

d/
-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 13:50:40 -0700

Dave Crocker wrote:

> When moving to a new key for a domain, may the same selector be used, 
> or is the signer required to use a different selector?

You must use a new selector. Otherwise, depending on cache etc,  you
might get indeterminate results.

       Mike

---

From: Jonathan Clark <[email-masked]>
Date: Tue, 11 Apr 2006 16:59:04 -0400

> might get indeterminate results.

If this is the case, doesn't it finesse the whole multiple-signature debate?

Jonathan

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Apr 2006 14:04:14 -0700

On Apr 11, 2006, at 1:50 PM, Michael Thomas wrote:

>> When moving to a new key for a domain, may the same selector be  
>> used, or is the signer required to use a different selector?
>
>

If the key is changed well prior to use and well after use, such as  
in a round-robin fashion, there should be little that prevents this  
technique.  It is not a limitation of DNS, as it is rather common to  
anticipate these transitions by setting the TTL for the affected  
resource record.

It will reduce the overhead when no record is found, rather than a  
different record with a key that is not intended to verify the  
message.  In that case, it would be good to establish a practice  
where a different selector is used to introduce a new key to minimize  
the verification overhead.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2006 22:35:08 +0100

Dave Crocker wrote:
> When moving to a new key for a domain, may the same selector be used, or 
> is the signer required to use a different selector?
> 
> Stated differently:  Is it true that a given selector+domain DNS lookup 
> name will produce at most one key, forever?
> 
> I think some folks believe that it might produce a different key, over 
> time, and I'd like us to be clear about whether it can do that.

Well, this was sort-of discussed in Dallas in response to issue
#1230 (raised by me, roundly rejected by all:-) where there was a
strong consensus not to include additional structure in selectors on
the basis that any such guidance didn't belong in the base document.

So, from the point of view of base- I believe we have decided that
its 1:1 only. I guess that decision was incidental to handling the
dead issue, but I got a strong impression that this was what people
wanted. And I'd be very surprised if that consensus had changed.
And section 3.1 of base is pretty clear about this, even if it says
"should" and not "MUST".

That doesn't stop someone else coming up with whatever scheme they
like later on of course. And I suspect that no-one would notice
if someone reused a selector a decade down the road. If you changed
every week you might generate hassle (for yourself) since someone
may quite reasonably have cached the key beyond the TTL of the
record.

Anyway I bet that getting people to change their keys at all will
be the problem!

Stephen.

PS: Issue #1230: https://rt.psg.com/Ticket/Display.html?id=1230

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2006 22:36:46 +0100

> If this is the case, doesn't it finesse the whole multiple-signature debate?

I don't understand why that'd be the case given that each signature
"points" at its own selector.

S.

---

From: Jonathan Clark <[email-masked]>
Date: Tue, 11 Apr 2006 17:47:23 -0400

> "points" at its own selector.

[ Also having this discussion with Doug Otis offlist... ]

My thought here was that the primary use of multiple signatures is for
rolling keys (and/or algorithms). You slap a new key under the existing
selector and sign messages with both keys, so preserving signature
validity for old messages. Doug points out that squeezing 2 keys into
one (TXT?) record may be a tight fit :-)

Now if you put the new key under a new selector, old messages keep pointing
to the old selector, and new ones now point to the new selector, so there's
no point to having multiple signatures for this usage.

Doug points out that there are other reasons for multiple signatures, such
as redistribution (listservs, forwarding), and I suppose he's right.

BTW this changes my view of whether "x=" is valuable - if it really is
one key per selector, then I no longer think that "x=" is valuable.

Jonathan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2006 23:04:49 +0100

Hi,

> one (TXT?) record may be a tight fit :-)

Yes. One key per TXT record would be a reasonable restriction.

> no point to having multiple signatures for this usage.

Ah. You mean if you've also deleted the old key record from DNS. Well,
yes, but during a transition where the same entity is signing twice, I
would guess that deleting the old key would be a bit counterproductive
in that case.

> one key per selector, then I no longer think that "x=" is valuable.

Feel free to revise your posting under that thread. I'll try base
the sums on people's last opinions. (But I'll probably discount all
postings from anyone who expresses too many opinions. How many is
too many? Not saying:-)

S.

---

From: "Dave Crocker" <[email-masked]>
Date: Tue, 11 Apr 2006 22:53:58 +0000 GMT

Just to be clear, I am not asking about the syntax or structure of the selector.  I am asking about different keys under the same selector.  They are essentially orthogonal issues, unless I am missing something.

/Dave

--
bbiw.net

(via handheld)  

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2006 22:35:08 
To:[email-masked]
Cc:DKIM IETF WG <[email-masked]>
Subject: Re: [ietf-dkim] multiple keys under same selector+domain?

Stephen.

---

From: Jonathan Clark <[email-masked]>
Date: Tue, 11 Apr 2006 18:51:42 -0400

> would guess that deleting the old key would be a bit counterproductive

Well, you don't delete the old key until all the messages signed with it
have reached their destinations or bounced. From the point of view of a
sender who is changing keys, once the new one is in place (under a new
selector) you might as well switch to using it, there's no value at all
in still using the old key, and hence none in signing with both keys
(in this case).

> postings from anyone who expresses too many opinions. How many is

Chuckle. What's that quote about "When the facts change, I revise my
opinions. What do *you* do?" My google-fu isn't up to the challenge...

Jonathan

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 16:21:39 -0700

Jonathan Clark wrote:
> rolling keys (and/or algorithms). 

The motivation is rolling algorithms, not keys. And that's _a_ reason,
but not the only reason.

> You slap a new key under the existing

Selector namespace is cheap; there's just no motivation I've
seen to try to recycle it. Why even try?

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Apr 2006 00:16:14 +0100

> in still using the old key, and hence none in signing with both keys

Well, you may want to sign twice for an extended period, say if
sig1 is rsa-sha1 and sig2 is rsa-sha256 and it takes a year or more
before you're confident that a sufficient number of peers have
deployed sha256 verifiers. And of course, we do expect another
such transition in <5 years (starting when the new improved NIST
hashing process reaches its conclusion).

And there remain the list-related multiple signature cases as
well in any case.

Result: keys-per-selector and multiple signatures are, for us,
different issues.

S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Apr 2006 17:39:30 -0700

> selector 

but i thought that that was exactly what one is supposed NOT to do.  a selector 
gets at most one key.

this disparity of the group's understanding about key management strikes me 
as... key.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Apr 2006 17:46:16 -0700

> deployed sha256 verifiers. 

This presumes that a signature is expected to validate a year after it was 
created.  Since DKIM is for transit, why would anyone expect a validation to 
occur that far into the future?

d/
-- 

Dave Crocker

---

From: Jonathan Clark <[email-masked]>
Date: Tue, 11 Apr 2006 21:11:53 -0400

>>      You slap a new key under the existing selector 

> but i thought that that was exactly what one is supposed NOT to do.  
> a selector gets at most one key.

I think this discussion has brought that out. It has sharpened my
understanding - yesterday I thought that you *would* stick multiple
keys under a single selector. It makes a lot of sense to use a single
key per selector (as someone said, selector space is cheap), it was
just a new concept to me. The rest of the discussion is (to my mind)
purely about the utility of multiple signatures. Personally I can't
see a point in using these when rolling keys (or algorithms, as a
matter of pragmatism I figure that if you're rolling an algorithm,
you'd roll a new key to go with it). Doug Otis has pointed out that
there are other reasons to use multiple signatures, and I accept
those examples.

> this disparity of the group's understanding about key management strikes me 

Groan. Now stop that already :-)

Jonathan

---

From: Jonathan Clark <[email-masked]>
Date: Tue, 11 Apr 2006 21:20:40 -0400

> hashing process reaches its conclusion).

OK, I see that now. Doug also mentioned mail forwarding and listservs.

> Result: keys-per-selector and multiple signatures are, for us,

Thanks for convincing me. I'm glad we aired the one key per selector
business as part of this thread.

And I formally change my vote on "x=" to 'dump it' :-)

Jonathan

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 18:29:39 -0700

Dave Crocker wrote:
> but i thought that that was exactly what one is supposed NOT to do.  a 
> selector gets at most one key.
> 
> this disparity of the group's understanding about key management strikes 
> me as... key.

Well, there is a general proscription about duplicate tags in the
headers and RR's, so that would pretty much invalidate any multi-key
RR right there.

		Mike

---

From: Mark Delany <[email-masked]>
Date: Wed, 12 Apr 2006 03:36:08 +0000

On Tue, Apr 11, 2006 at 09:11:53PM -0400, Jonathan Clark allegedly wrote:
> keys under a single selector.

This does bring out the point about the need for non-normative text
about these various issues.

Multiple signatures - when and why
Multiple selectors - how and why
Key rotation - how and why

Along with best practices might be worst practices, such as:

Selector re-use
Multiple RRs per Selector label

Mark.

---

From: Mark Delany <[email-masked]>
Date: Wed, 12 Apr 2006 03:40:10 +0000

On Tue, Apr 11, 2006 at 05:46:16PM -0700, Dave Crocker allegedly wrote:
> created.  Since DKIM is for transit, why would anyone expect a validation 
> to occur that far into the future?

I don't think that's his point. His point is that it takes a year to
be confident that sufficient verifiers understand the new signature
type. IOW that year is the transition time for verifiers.

So yes, Jonathan, you have precisely described the case for two
signatures being generated by a signer - as a transition away from a
deprecated algorithm.

Mark.

---

From: Jonathan Clark <[email-masked]>
Date: Wed, 12 Apr 2006 10:53:10 -0400

>> to occur that far into the future?

So *should* we continue to think of DKIM as being transit-only?

It seems like there is value in allowing MUAs to re-validate messages
long after they are received in a mailbox, and to be able to distinguish
between cases such as:

	invalid key
	key was valid when the message was received, but has now expired
	algorithm was valid when message received, but sender has now
		deprecated it
	and so on

The overhead would be to keep old keys lying around in the DNS forever,
and perhaps some more metadata.

Jonathan

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Apr 2006 08:03:09 -0700

> long after they are received in a mailbox, and to be able to distinguish
...
> and perhaps some more metadata.

1. That's quite a large bit of overhead.

2. "seems like there is value" seems a bit vague.  What do you see as the 
compelling benefit to be obtained from this?  How would it be useful to make the 
distinctions you list?

3. Is there any reason that this enhanced requirement could not be added later, 
so that the initial benefits and burden of DKIM are kept more focused during 
initial adoption and deployment?

d/

-- 

Dave Crocker