Subject: [ietf-dkim] New Issue: Overview service-type and delegation

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 21:52:09 -0700

Section 4.1 paragraph 3 talks about the service type (s=) constraint in 
key records, and goes on to say that it is helpful when delegating 
signing authority.  s= was included to provide expansion capability 
should, at some point, some service other than email decide to use 
DKIM.  If and when some other service does use DKIM, the ability to 
constrain a key to signing email only would help delegation.  In the 
meanwhile, there isn't any benefit to delegation as a result of s=.

I suggest that the paragraph be deleted.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 22:18:51 -0700

> I suggest that the paragraph be deleted.

You suggest having the DKIM Overview make no comment on the s= parameter?

The signing specification's explanatory text for s= is:

    "This tag is intended to constrain the use of keys for other purposes".

If there is something inaccurate in the Overview text, what is it?

As for "included to provide expansion capability", I don't understand what this 
means.  The signing spec text says it was included for a different purpose, but 
that it *includes* an expansion capability, to list other services.

You further seem to indicate that s= is not currently useful but would be if it 
listed other services.  (I well might be misunderstanding this part of your 
text.)  In any event, either the capability has currently utility, or it was a 
mistake to put it in the spec.  Which are you saying?

d/

-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 22:30:37 -0700

Dave Crocker wrote:
>
> Jim Fenton wrote:
>> Section 4.1 paragraph 3 talks about the service type (s=) constraint 
>> in key records, and goes on to say that it is helpful when delegating 

It's not strictly inaccurate, since it says "intended to be helpful", 
which is true.  But I don't want to give the impression to the reader 
that using s=email in their keys is going to provide any immediate 
benefit, because there aren't any other services using DKIM.
>
> As for "included to provide expansion capability", I don't understand 
> what this means.  The signing spec text says it was included for a 
> different purpose, but that it *includes* an expansion capability, to 
> list other services.
>
> You further seem to indicate that s= is not currently useful but would 
> be if it listed other services.  (I well might be misunderstanding 
> this part of your text.)  In any event, either the capability has 
> currently utility, or it was a mistake to put it in the spec.  Which 
> are you saying?

The current utility is that, while extensions can be added any time, 
constraints need to be added up front.  So if another service besides 
email wanted to use DKIM and its key infrastructure, it wouldn't be 
possible to cause new keys created for that service to not also be used 
for email unless we define it now so that "legacy DKIM implementations" 
in the future will honor the constraint.

So it doesn't have any direct utility at present, but IMO it was not a 
mistake to put it in the spec either.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 22:48:25 -0700

Jim Fenton wrote:
> Dave Crocker wrote:
>> The signing specification's explanatory text for s= is: "This tag is
>> intended to constrain the use of keys for other purposes". If there is
>> something inaccurate in the Overview text, what is it?
> 
> It's not strictly inaccurate, since it says "intended to be helpful", which
> is true.  But I don't want to give the impression to the reader that using
> s=email in their keys is going to provide any immediate benefit, because
> there aren't any other services using DKIM.

The Overview document's discussion of DKIM's details is actually pretty careful 
not to talk about efficacy .  Sowhether something is "useful" or has "immediate 
benefit" is something the document seeks to avoid saying anything about.

>> You further seem to indicate that s= is not currently useful but would be
>> if it listed other services.  (I well might be misunderstanding this part
>> of your text.)  In any event, either the capability has currently utility,
>> or it was a mistake to put it in the spec.  Which are you saying?
> 
> constraints need to be added up front.  So if another service besides email
> wanted to use DKIM and its key infrastructure, it wouldn't be possible to
> cause new keys created for that service to not also be used for email unless
> we define it now so that "legacy DKIM implementations" in the future will
> honor the constraint.

Actually, this all touches on the question of trying to recruit signature 
verifiers into the task of enforcing a signer's internal policies.  That's what 
restrictions on authorization to signing are.

In spite of your ending statement to the contrary, your explanation really does 
seem imply that the s= mechanism is useful in its current form. An assertion 
that it's necessary to have it now only makes sense if it has benefit now, even 
if the benefit is building a utility "infrastructure" for later use.

At best, the benefit of having s= defined now depends on whether people are 
setting s=email now.  Are they?  Should they?  How will they know?

My point is that the Overview document seeks to describe s= in the most limited 
way it can, while at least saying something meaningful.

Deleting a discussion of s= seems inappropriate, as does having the text say 
more, since it's a bit of an oddity and I doubt we (the community) understand it 
very well.

d/
-- 

   Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Mon, 24 Mar 2008 22:49:40 -0700

> mistake to put it in the spec.  Which are you saying?

As I understood it, s= is about minimizing a compromise at the  
signing end. If a verifier in another context sees content signed by  
a key that says s=email, then they know that the private key at d=  
has been compromised.

So s= is about a verifier helping to minimize the damaged of an  
internal key compromise at d=. Whether this is a reasonable risk or  
not to encode in the protocol is a question.

Also, I don't understand what "s= helps delegation" means, that Jim  
refers to.

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 25 Mar 2008 01:35:23 -0400

um, erm, ahem

ss 4.1 para 3 is supposed to be talking about the use of the s= selector 
value to choose which signature key is being used.

But Jim mistook the paragraph to be talking about the s= service type 
value that can be found *within* a signature key.

This indicates to me that our text led Jim astray.

	Tony Hansen
	[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Mon, 24 Mar 2008 23:04:42 -0700

On Mar 24, 2008, at 10:30 PM, Jim Fenton wrote:

> constraints need to be added up front.

Okay, I'll bite. Why is this a good idea? By way of contrast, when an  
A RR is added to a DNS zone saying what address to use, no constraint  
is placed on the sorts of connections that can be made to that  
address. When an MX is added to a DNS, nothing is said about using it  
or not using it for purposes other than finding a mail server (they  
are of course used for anti-spam checking amongst other things).

So I sort of struggle over why we would want to try and constrain the  
use of a DKIM RR, particularly when we rely on the good graces of a  
verifier to enforce that constraint and whether they do so or not is  
entirely unknown to the DKIM RR publisher.

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 25 Mar 2008 01:55:00 -0400

ignore this message.

<wet noodle time>

Never post messages close to 2 am.

</wet noodle time>

sigh

	Tony Hansen
	[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 09:00:02 -0700

Dave Crocker wrote:
>> email
> Actually, this all touches on the question of trying to recruit 
> signature verifiers into the task of enforcing a signer's internal 
> policies.  That's what restrictions on authorization to signing are.

The same could be said about restrictions on hash and signing 
algorithms, yet those are essential.

>
> In spite of your ending statement to the contrary, your explanation 
> really does seem imply that the s= mechanism is useful in its current 
> form. An assertion that it's necessary to have it now only makes sense 
> if it has benefit now, even if the benefit is building a utility 
> "infrastructure" for later use.
>
> At best, the benefit of having s= defined now depends on whether 
> people are setting s=email now.  Are they?  Should they?  How will 
> they know?

Are they:  I haven't seen a key with s=email yet, although I'll have to 
admit that I don't look at a lot of selectors.

Should they:  They should as soon as they start using DKIM for services 
other than email, especially if they want to delegate keys to 
parties/agents not authorized to send email on their behalf.  But until 
someone defines use for DKIM in a service other than email, s=email is a 
tautology, so I don't think it's important to state.
>
>
> My point is that the Overview document seeks to describe s= in the 
> most limited way it can, while at least saying something meaningful.
>
> Deleting a discussion of s= seems inappropriate, as does having the 
> text say more, since it's a bit of an oddity and I doubt we (the 
> community) understand it very well.

I'm puzzled that you want to include text on a mechanism that we (the 
community) don't understand well, because we're likely to get it wrong 
in that case.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 09:19:49 -0700

> are of course used for anti-spam checking amongst other things).

I don't follow the A or MX examples; I don't see them as defining 
constraints.
> entirely unknown to the DKIM RR publisher.

Suppose that someone defined a standard for signing SIP INVITEs with 
DKIM signatures.  (I know, SIP Identity uses an entirely different 
mechanism.)  They might define s=sip for that service.  A domain using 
DKIM for both email and sip might (should?) use different keys for the 
two services, and as you pointed out in your previous message this 
limits the scope of an internal compromise of a private key.  It also 
limits the ability of an external party that has been delegated a key 
for a particular service to (mis)use that key for other, unauthorized 
services.

Good graces?  It's in the verifier's own interest to accept only valid 
signatures, so this doesn't seem like much of an imposition.

-Jim

---

From: Mark Delany <[email-masked]>
Date: Tue, 25 Mar 2008 09:28:53 -0700

On Mar 25, 2008, at 9:00 AM, Jim Fenton wrote:
>>>> if it listed other services.  (I well might be misunderstanding  
>>>> this
>>>> part
>>> cause new keys created for that service to not also be used for  
>>> email
>>> unless

But the failure mode is quite different. If the verifier ignores or  
mis-interprets instructions on hash and signing algorithms, the  
verify process fails-closed. If the verifier ignores s= instructions,  
the verify process fails-open.

As a principle, I would have thought that a fail-closed outcome would  
be something we prefer if the verifier does the wrong thing.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Tue, 25 Mar 2008 09:55:30 -0700

> It also limits the ability of an external party that has been  
> delegated a key for a particular service to (mis)use that key for  
> other, unauthorized services.
>

That's probably the best reason for it. In any event, this is surely  
moot at this stage. Most protocols end up with unused or under-used  
parts to them. It's a pity my Mum never warned me that protocol  
design has much to do with prophesying.

Mark.

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 14:03:43 -0400

Jim Fenton wrote:

> Are they:  I haven't seen a key with s=email yet, although I'll have
> to admit that I don't look at a lot of selectors.

I have.  Also s=mail, s=mx, s=mta23, s=domainkeys, and other strings
that our more-or-less human brains might want to interpret as carrying
additional meaning.

I haven't, however, seen any indication that those strings were chosen
with the intention of also having s=usenet, s=rss, s=sip,
s=antidisestablishmentarianism, or other indicators that a specific
selector would be used solely for non-email purposes.

--
J.D. Falk
Receiver Products
Return Path

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 12:44:10 -0700

> selector would be used solely for non-email purposes.

Are you perhaps confusing s= in the signature (selector name) with s= in 
the key record (service type)?  It's the latter that we're discussing.

-Jim

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 16:28:47 -0400

Jim noticed:

>  Are you perhaps confusing s= in the signature (selector name) with s=
> in the key record (service type)?  It's the latter that we're
discussing.

Yep, I must be confusing those.

Is it too late to change the letter?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2008 21:23:51 -0700

> tautology, so I don't think it's important to state.

We seem to have a disconnect.  You said that s= needed to be in the protocol 
now.  If it isn't used now, then what is the benefit of having it in the 
protocol now?

(I'm not arguing for a change in the specification, but am trying to argue for 
having the Overview include no more discussion than a basic regurgitation of the 
specification's statement of what the option is for. On the other hand, making 
no mention of the option encourages confusion, since it is part of the current 
specification and failing to refer to it leads to obvious "what is this for?" 
questions.)

> community) don't understand well, because we're likely to get it wrong 

Because it is part of the specification.  Having the Overview fail to refer to 
it does not remove it from the specification.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2008 21:45:56 -0700

Jim Fenton wrote:
> Dave Crocker wrote:
>> Jim Fenton wrote:
>>> Dave Crocker wrote: The current utility is that, while extensions can be 
>>> added any time, constraints need to be added up front.  So if another 
>>> service besides email wanted to use DKIM and its key infrastructure, it 
>>> wouldn't be possible to cause new keys created for that service to not 
>>> also be used for email unless we define it now so that "legacy DKIM 
>>> implementations" in the future will honor the constraint.
>> 
>> verifiers into the task of enforcing a signer's internal policies.  That's 
>> what restrictions on authorization to signing are.
> 
> The same could be said about restrictions on hash and signing algorithms, yet
>  those are essential.

Because there is no interoperability if the two participants apply different
hash algorithms to the same message.

In other words, conformance to core technical details is rather different from
attempting to direct the other side to apply the origination-side's local
enforcement policies for who is authorized to use a key and what they are
authorized to use it form.

>> My point is that the Overview document seeks to describe s= in the most 
>> limited way it can, while at least saying something meaningful.
>> 
>> Deleting a discussion of s= seems inappropriate, as does having the text 
>> say more, since it's a bit of an oddity and I doubt we (the community) 
>> understand it very well.
> 
> community) don't understand well, because we're likely to get it wrong in 
> that case.

Lack of deep understanding is why the discussion is so brief (and superficial.) 
Having *some* discussion is warranted by virtue of the feature being in the spec.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2008 22:21:54 -0700

Ahh.  Indeed.

Yes, having those in the DNS record always struck me as oddly unnecessary.

d/

Jim Fenton wrote:
> Dave Crocker wrote:
>>
>> Jim Fenton wrote:
>>> Dave Crocker wrote:
>>>> Jim Fenton wrote:
>>>>> Dave Crocker wrote: The current utility is that, while extensions 
>>>>> can be added any time, constraints need to be added up front.  So 
>>>>> if another service besides email wanted to use DKIM and its key 
>>>>> infrastructure, it wouldn't be possible to cause new keys created 
>>>>> for that service to not also be used for email unless we define it 
>>>>> now so that "legacy DKIM implementations" in the future will honor 
>>>>> the constraint.
> You're referring to the a= tag in the signature (which tells what 
> algorithms are used to generate the signature) while I'm referring to 
> the h= and k= tags in the key record.  They constrain the signature and 
> hashing algorithms that may be used to generate signatures with that 
> key.  This is required to prevent the use of weaker algorithms than the 
> signing domain intends to use.
> 
> -Jim
> 

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 22:01:29 -0700

Dave Crocker wrote:
>> Should they:  They should as soon as they start using DKIM for 
>> services other than email, especially if they want to delegate keys 
>> to parties/agents not authorized to send email on their behalf.  But 
>> until someone defines use for DKIM in a service other than email, 
>> s=email is a tautology, so I don't think it's important to state.
>
> We seem to have a disconnect.  You said that s= needed to be in the 
> protocol now.  If it isn't used now, then what is the benefit of 
> having it in the protocol now?
>
> (I'm not arguing for a change in the specification, but am trying to 
> argue for having the Overview include no more discussion than a basic 
> regurgitation of the specification's statement of what the option is 
> for. On the other hand, making no mention of the option encourages 
> confusion, since it is part of the current specification and failing 
> to refer to it leads to obvious "what is this for?" questions.)

The benefit is in order to cause verifiers to check for s= if it is 
present.  This enable the potantial that DKIM could be used for other 
services.

>> community) don't understand well, because we're likely to get it 
>> wrong in that case.
>
> Because it is part of the specification.  Having the Overview fail to 
> refer to it does not remove it from the specification.

So the Overview must mention every mechanism in the specification?  It 
doesn't.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 22:17:44 -0700

-Jim

---

From: Tony Hansen <[email-masked]>
Date: Thu, 27 Mar 2008 14:33:02 -0400

I see a couple things going on in this thread.

    1)	It's clear to me that we need to be *very* careful within the 
document whenever we refer to any of the keywords to make it totally 
clear whether we're talking about signature keywords or dns key 
keywords. Several of the messages in this thread made mistakes of this 
nature. In particular, using "signature key s=" could be misread as 
either one. (There was a similar problem in the email world until we 
learned to be very careful about differentiating between 
rfc2821.mailfrom and rfc2822.from, etc.)

I'm going to suggest that we take a pass through the document and, 
anywhere we refer to a keyword, use either signature. or dnskey. as a 
prefix, as in signature.s= and dnskey.s=.

    2)	There's a tussle going on here between documenting how we *know* 
dkim can be used today and how we think it will be used in the future. 
There are certain thing's we've put in to the base spec that we think 
will be useful in the future, but don't really know for certain that 
they are indeed useful or will be used the way we intended. They're for 
future use. Dnskey.s= is one example of this.

Now in my mind, an overview document *does* need to go into how we 
expect the base spec to be used. We'd be doing a disservice to our 
readers if we ignored that aspect. But at the same time we probably do 
need to be careful to differentiate more clearly between the two areas.

	Tony Hansen
	[email-masked]