Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 22:23 -0400

On Thu, 27 Jul 2006 16:15:03 -0700 Jim Fenton <[email-masked]> wrote:
>Scott Kitterman wrote:
>> On Thursday 27 July 2006 18:31, Jon Callas wrote:
>>   
>>>> If I use isp.example.com and they sign messages with my name and a
>>>> key (theirs
>>>> or mine, doesn't matter) and they also sign messages actually sent
>>>> by joe
>>>> spammer (another one of their customers) with my name and a key
>>>> (again,
>>>> theirs or mine), then it sucks to be me.  That's the problem.
>>>>       
>>> No, it doesn't suck to be you. The first letter of DKIM stands for
>>> "Domain." It sucks to be example.com.
>>>
>>>     
>> To clarify, by me, I meant my domain.  The problem is that in this type 
of 
>> scenario, there is no way to externally distinguish  between mail 
actually 
>> sent by the vanity domain owner and mail sent by another customer of 
>> isp.example.com  
>>   
>I guess this means that isp.example.com is not worthy of your delegation
>of signing authority to them, and you should shop elsewhere (find a more
>reliable ISP, or sign your own messages).  I think the ISPs will get it
>right fairly quickly if they lose business as a result of not
>authenticating mail submission properly (or otherwise fixing whatever
>mechanism allowed Joe Spammer's message through).
>
Yes.  What I want as a small domain owner is the ability to publish a 
policy record that say that for mail sent (for some definition of sent that 
we will probably have to argue about later) from my domain, the domain(s) 
authorized to sign are ...

If/when I switch providers I can change the list.  This is the simplest 
approach I can think of to put small domain owners on the same footing as 
domains running dedicates MTAs.  I think from the perspective of the domain 
owner it is easier than managing public keys in DNS.

For many small domains, signing themselves will be completely out of reach 
due to cost and lack of expertise.

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

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 22:51:01 -0400

Scott,
Perhaps an easier way, instead of you having to manage a DNS policy
record, you offload that to your provider
Policy.DKIM.foo.bar.com is a alias to dkim.provider.com who states the
policy you request. When changing outbound email providers the new
provider aliases policy.foo.bar.com to new.dkim.provider.com.

Now if a small domain is managing their own dns I imagine it would not
be too demanding to use their own mta that can sign. Its not that
difficult.
The expertise to manage one makes he other rather trivial.
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 Scott Kitterman
Sent: Thursday, July 27, 2006 10:23 PM
To: [email-masked]
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

of 
actually 
Yes.  What I want as a small domain owner is the ability to publish a 
policy record that say that for mail sent (for some definition of sent
that 
we will probably have to argue about later) from my domain, the
domain(s) 
authorized to sign are ...

If/when I switch providers I can change the list.  This is the simplest 
approach I can think of to put small domain owners on the same footing
as 
domains running dedicates MTAs.  I think from the perspective of the
domain 
owner it is easier than managing public keys in DNS.

For many small domains, signing themselves will be completely out of
reach 
due to cost and lack of expertise.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 23:36:01 -0400

> The expertise to manage one makes he other rather trivial.
Except what I've seen that it much more common is that neither is actually in 
house, but the MTA is provided by the ISP or domain host and the DNS service 
is provided by the registrar, so while there are different entities doing the 
work, it is all outsourced.

Most domain owners are, from my experience, not technically savvy at all.  
Running either their own DNS or MTA is well out of their reach.

Scott K

---

From: John Levine <[email-masked]>
Date: 28 Jul 2006 04:22:29 -0000

>authorized to sign are ...

Once again I ask: what possible use could a recipient make of this
assertion?

If your ISP signs your mail and, for whatever reason, the recipient likes
the ISP's domain, they'll accept your mail.  If not, they'll filter or
reject it.  How would an SSP assertion change that?

On the other hand, if your mail passes through some other relay or
forwarder which signs your mail on the way through, would you want the
recipient then to reject your mail?  If so, why?  If not, what point
is there to publish a list of signers?

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 02:36:39 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 28, 2006 12:22 AM
Subject: Re: [ietf-dkim] SSP complications, wa The URL to my paper ...

that
> Once again I ask: what possible use could a recipient make of this

I believe you are asking the wrong question. It is the verifier who will
make use the policy declaration. The verifier will make an assertion to
verify the signing declaration.  If it fails, there is strong evidenc that
this is a violation of the policy hence an immediate classification for
rejection.  If it passes, the verifier can accept it or pass it on to
another layer of subjective reputation stuff that really have nothing to do
with following a strong protocol.

Of course, verifiers will have the ultimate say with the help of local
policy administration decisions on what or how these checks will be done.

> reject it.  How would an SSP assertion change that?

Again, wrong question.  I think you are mixing Reputation, Certification
ideas and it really doesn't apply.  SSP has nothing to do with whether the
verifier likes or doesn't like your ISP domain

Reputation, Certification, etc is really whole different level of subjective
mail interpretation considerations and if I read the charter right, it is
out of scope and it can only serve to complicate discussions about SSP.

SSP or DSAP are about protecting the DKIM-BASE signing process from abuse.
It has nothing to do certification or reputation.

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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 03:08:55 -0400

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 27, 2006 10:23 PM
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

> due to cost and lack of expertise.

Frankly, I have been thinking how the majority my mail market customers will
react too.   Everything must be GUI and provided for them if you want the
features to be used.

All I know is that when presented with the most generalized description of
DKIM, by far, the feedback has been that if given they choice, they nearly
all wanted exclusive signing practices.  Which basically means they don't
want anyone screwing around with their domain properties regardless on how
that was done.

To this day, I still don't see why anyone will want to sign a domain for
public exposure with a cross your finger, "hope it won't break" thinking.
i.e, use it on a list system of today.

But at the very least, if we wanted to allow for this, then we ought to see
how to minimize the impact of what I see will be a high false positive rate
(or false negative depending on how you want to look at it).

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jul 2006 11:23:58 +0100

> is there to publish a list of signers?

I assume his concern was with unsigned (or maybe even DKIM-signed?)
mail from a bad actor, purporting to be from his little domain.

If the verifier looked up the little domain's SSP and found that e.g.
all mail from little domain is supposed to be signed by the ISP then
they might more easily detect bad stuff (ignoring real signatures from
the ISP that get broken for now).

Whether or not the work for a bad actor to create a message with what
looks like a broken signature from the ISP is a big enough deal is a
valid question. Since SSP helps automate this, the bad actor's code
can take advantage too. I don't claim to know where the right balance
lies there.

Anyway I guess this is just another argument to require support for
inclusion of some kind of allowed-signer list in SSP statements, and
maybe also for a requirement that the SSP statements should be able
to be "sourced" independently of key records. I guess the WG should
consider both requirements and adopt 'em or drop 'em, so including
them for now is probably right.

Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 28 Jul 2006 09:21:43 -0400

On Friday 28 July 2006 00:22, John Levine wrote:
> > that we will probably have to argue about later) from my domain, the
> > domain(s) authorized to sign are ...
>
I think that's an argument against the concept of SSP in general and not this 
specific requirement.  I thought that issue had been settled.

The point is to put small non-technical domain owners on an equal policy 
footing with domain owners with the ability to run dedicated mail servers.  
The difference between first party and third party is that in first party the 
signing domain is assumed to be authorized by the sending domain to do so 
since they are the same.  I think there should be a way to make the same 
assertion explicitly for some external entity.

In terms of usage, I would expect mail signed by a third party that is 
explicitly authorized to be treated the same as first party signatures.

Your argument seems to me to be that it's all going to come down to a 
reputation system anyway so why bother with policy at all.  I understand that 
argument and do not agree with it.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 10:30:31 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

> them for now is probably right.

+1 for both - signer list, independent records.

Incidentally, the DSAP proposal currently considers an "allow list" tag
definition:

4.3.  DSAP Tag; 3pl=<dom-list>;

   The 3pl= is an optional tag that defines a list of 3rd party domains
   who are allowed to DKIM sign the message as a 3rd party signer.  This
   tag is ignored unless 3rd party signing policy is expected or
   optional (3p=always or 3p=optional).

   <dom-list> is a comma delimited list of domain names.

   Example:

   3pl=isp.com,outsource.com,mailinglist.com;

One initial and obvious design consideration is length limit related. One
reviewer did suggest some 'include' concept or protocol to access large
list.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Jul 2006 07:58:13 -0700 (PDT)

>   3pl=isp.com,outsource.com,mailinglist.com;

That "3pl" may have been misspelled in the table listing possible tags
as "dl". Please check.

> One initial and obvious design consideration is length limit related. 
> One reviewer did suggest some 'include' concept or protocol to access 
> large list.

SPF has worked those details out so you might consider its apprach.
But personally I think general "include" is too open and better
is to use something similar to SPF macros where reference can be
made to another locator (with locator dns name based on From email
address or domain) to verify that domain is listed there but
there would never be any more then one additional dns lookup.
An illustration of that concept is:
  3pl={d}._3pl;
which when present with "From: [email-masked]" causes lookup
at 'example.com._3pl._policy...'

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Jul 2006 08:01:18 -0700

>reviewer did suggest some 'include' concept or protocol to access large
I'd venture to say that "include" ala SPF is specific NON-REQUIREMENT,
as it violates the requirement that the query operation provide a 
deterministic
number of queries for discovery/fetching.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Fri, 28 Jul 2006 15:32:47 +0000

> number of queries for discovery/fetching.

+1

I see very marginal benefit to that sort of indirection and a very
large cost in operational complexity and test cases.

Besides which, inheriting topology might be a common convenience that
justifies complexity in an IP based model, but inheriting policy seems
a much less likely and thus less compelling reason in a domain based
model.

Mark.

---

From: John L <[email-masked]>
Date: Fri, 28 Jul 2006 11:46:26 -0400 (EDT)

> the ISP that get broken for now).

If that's what it means, all my mail is signed by one of these domains, 
that's OK (give or take the usual question of whether SSP is useful at 
all.)

The prior message's wording suggests that ONLY these domains can sign, and 
if anyone else signs it's bogus.  That's nuts.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 12:13:59 -0400

+1.

The allow list was added primarily recognizing it as a requirement
understanding it would be one of the design issues to work out.

Since the limitation would be part of the total query size anyway, one
consideration I had in mind was to suggest TCP stream lookups instead to
avoid any UPD truncate responses.   But off hand, the worst case is 2
lookups, a UCP truncate followed up by switching to TCP.     This is one
area I will punt to the DNS experts.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Jul 2006 09:18:35 -0700

>a much less likely and thus less compelling reason in a domain based
What occurs to me is that _any_ form redirection -- even if it were 
limited to
one entry -- could lead to looping, which definitely violates the 
deterministic
property. That is:

a.com: "signed-by=b.com;"

b,com: "signed-by=a.com;"

This is one of the many things that are possible and problematic with 
SPF. If we
include any of this at all, it seems to be that the depth of indirection 
should be
hard coded to, say, 1.

Perhaps a better mechanism is to just completely disallow jumps from
one domain namespace to another, ie that any indirection must take place
in the subtree of the consulted domain, and that it's just, say, an n stage
process instead of a potential loop.

          Mike

---

From: Mark Delany <[email-masked]>
Date: Fri, 28 Jul 2006 16:26:07 +0000

> process instead of a potential loop.

Assuming DNS, I would say let's just use the mechanism "as it". Loop
detection and query truncation is a function of the query system, not
the application.

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 12:31:46 -0400

----- Original Message -----
From: "william(at)elan.net" <[email-masked]>

> That "3pl" may have been misspelled in the table listing possible tags

You reviewed an earlier draft-01 which had it as "dl". I changed it to 3PL,
made other reviewer changes/input, renumbered the draft to 00 and submitted
as so. Hopefully it will be announced today. The latest is:

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.xml

Are you suggesting it be "dl=" again?

> at 'example.com._3pl._policy...'

Yes, you suggested this for the draft.  But I think this is still open how
to best do this, if at all.  The barrier is DNS packet size limitations.
The worst case is a UDP Truncate response followed up by a TCP Stream query,
so 2 lookups.  It is better to recommend to always begin with a TCP request
to minimize the request?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jul 2006 09:35:18 -0700

> understanding it would be one of the design issues to work out.

A list of designated signing domains would be indicative of a small  
outfit.  Larger organizations should have an IT staff to make the  
delegation process transparent.  As such, one should be able to  
assume that the designation list will fit within a DNS UDP query.   
That still should satisfy most of the needs for the smaller outfits.

Keep this simple.  Don't expect TCP fallback or EDNS0 will be  
available.  There should be no reason for creating a script language  
either.  A list of designated signing domains with some type of  
terminator to close this list is all that is needed.  Most of your  
DASP fields and other related settings would then be redundant and  
not very useful.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Jul 2006 15:51:43 -0700 (PDT)

> http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.xml

Those are the ones I reviewed, the "dl" appears in the table in section 4

> Are you suggesting it be "dl=" again?

3pl= is fine; personally I don't care much as long as its consistent.

> to best do this, if at all.  The barrier is DNS packet size limitations.

Which is why this type of redirection is better.

With DNS-TCP you end up with 9 packets: 2 for UDP to find out that 
response is too large and change to TCP, 3 for SYN/ACK to establish
TCP session, 2 to send actual request and receive a response and
2 more for FIN session end (I maybe slightly wrong by 1 or 2 packets
as some of the packets can possibly be combined, i.e. FIN).

For above redirection you always end up with 4 packets (2 for original
request/response and 2 more for 3pl={d} redirected request/response).

Also if you have very large dns record this is bad (dns is not
designed for it and many such records are operational problems
both due to abuse and due to use of dns cache on ISP systems).
With redirection you will always end up with small dns record -
the first one for DSIP policy itself with list very small just
containing macro (3pl={d}) where as second dns record just needs
to exist but actually can be 0 size (or we can talk about what can
be put there that matters), this is like "a" operator in SPF.
The size of the records will also not change even if you have
1000 domains so dns queries will all be small.

Additional benefit is that with redirection whoever put up the
policy can actually produce some statistics about which of the
3pl listed domains are actually seen in the emails (based on
dns logs for <domain>._3pl._policy).

> The worst case is a UDP Truncate response followed up by a TCP Stream 
> query, so 2 lookups.

Its not quite that simple when comparing UDP to TCP - see above.

> It is better to recommend to always begin with a TCP request to minimize 
> the request?

This is not how DNS-TCP supposed to work and in general TCP Session 
establishment is expensive on its own; in the end up you still have 
packets being exchanged then 2 separate dns udp requests and add
to that slight overhead for OS network kernel associated with each
TCP session too.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jul 2006 16:24:05 -0700

On Jul 28, 2006, at 3:51 PM, william(at)elan.net wrote:

> policy can actually produce some statistics about which of the 3pl  
> listed domains are actually seen in the emails (based on dns logs  
> for <domain>._3pl._policy).

This seems like a clever idea, but there is really no need for two  
queries.

The query would be <signing-domain>._dkim-policy.<domain>

$ORIGIN <domain>
*._dkim-policy			RR "DSDL: <domain> MODE:closed"
designated-1._dkim-policy	RR "DSDL: <designated-1> MODE: closed"
designated-2._dkim-policy	RR "DSDL: <designated-2> MODE: closed"
*.designated-3._dkim-policy	RR "DSDL: <*.designated-3> MODE: closed

Either a signing domains is designated or it is not.  There is no  
reason to indicate the designated domains is also within the same  
domain as that of the OA.  The only other useful element to valid a  
source would be to indicate whether other non-designated domains are  
valid sources.  When other non-designated domains are allowed (open),  
it seems pointless to attempt to indicate whether these undefined  
domains should also be using DKIM.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jul 2006 08:59:18 -0700

Stephen Farrell wrote:
> all mail from little domain is supposed to be signed by the ISP 

What proposed SSP flags, configuration and usage will enable a receiver to know
that a particular (rfc2822.From?) domain's messages must be signed by a
particular ISP?

d/

-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Jul 2006 17:11:36 +0100

> that a particular (rfc2822.From?) domain's messages must be signed by a

I would assume that were the WG to adopt that requirement then there'd
have to be some way to retrieve a list of signer identities of some
sort based on the rfc2822.From value along with a flag indicating that
all messages must be signed by one of the listed signers. Something
like that anyway.

The fact that the signer in the example is an ISP and not something
else is incidental, i.e. I didn't interpret the use-case as calling
for signer-roles or the like.

S.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Jul 2006 16:13:04 -0700

>that a particular (rfc2822.From?) domain's messages must be signed by a
I don't think it's hard to envision such a protocol element, where
I get stuck is how you do so in a way that doesn't blow out all kinds
of other requirements. It's tempting to put this sort of requirement in,
but if the end result is that it can't be done without violating other
more fundamental requirements then it should be eliminated. I've
been tentatively calling these sort of things "provisional" requirements
in that they need to

a) demonstrate a constituency
b) demonstrate that they can be done without violating other requirements.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 01:01:47 -0700

On Sun, 2006-07-30 at 16:13 -0700, Michael Thomas wrote:
> Dave Crocker wrote:
>
> > What proposed SSP flags, configuration and usage will enable a 
> > receiver to know that a particular (rfc2822.From?) domain's messages
> > must be signed by a particular ISP?
>   
> of other requirements. It's tempting to put this sort of requirement
> in, but if the end result is that it can't be done without violating
> other more fundamental requirements then it should be eliminated. I've
> been tentatively calling these sort of things "provisional"
> requirements in that they need to
> 

It is difficult to discuss requirements without also considering
requisite underlying mechanisms.  If a mechanism becomes too cumbersome,
then that requirement should be reconsidered.

Several have lent support to the general concept of a list of designated
signing domains.  The mechanism might be as simple as a list and a flag
that indicates whether non-designated domains are used.  A means to
designate a domain overcomes the dynamic issues related to sharing
private keys/selectors/domains/settings, delegating domain zones, or
directly handling DKIM.

There are techniques that ensure a mechanism for publishing a domain
list never involves more than one query and that always provides a small
answer suitable for DNS/UDP. A desire and a means seems to satisfy both
a & b requirements.

The list and flag offer a means to indicate:
 - no domain is designated for the OA. (no mail)
 - specific domains are designated for the OA.
 - non-designated domains are used. 

A designated signing domain should always employ DKIM.
A non-designated domain might not employ DKIM.

When DKIM signs OAs of a different domain, the OA may still desire a
means to limit their exposure to spoofing and to improve the delivery of
their messages.  The list approach allows this without also incurring
the need to deal with multiple signatures, weaknesses with MUA signing,
or making special arrangements with a DKIM provider.

-Doug