Subject: [ietf-dkim] SSP and o= values

From: Tony Hansen <[email-masked]>
Date: Sun, 26 Mar 2006 22:45:31 -0500

As promised at the dkim meeting, I'm resending a suggestion about o=
that was sent in November and again in February.

At the Wednesday meeting, it was suggested that we replace the single
character o=? (etc.) tags with tags like o=WEAK (etc.). The thrust of
the messages was that we should use something that is even more meaningful.

There were a couple of threads last November about changing o= to use
words and splitting out the semantics around the various semantic axes
that are covered by the value (sending mail, signature presence, 3rd
party signatures, redirect).

One message that I wrote had a table, showing what a couple possible
syntaxes might be for o=
(http://mipassoc.org/pipermail/ietf-dkim/2005q4/001307.html, slightly
modified here):

		o=-signature,-3ps	signature=never,3ps=never
?/WEAK		o=~signature,-3ps	signature=optional,3ps=never
~/NEUTRAL	o=~signature,+3ps	signature=optional,3ps=allowed
!/EXCLUSIVE	o=+signature,-3ps	signature=always,3ps=never
-/STRONG	o=+signature,+3ps	signature=always,3ps=allowed
./NEVER		o=nomail		nomail
^/USER		o=user			checkuser

William Leibzon also had suggestions along the same lines
(http://mipassoc.org/pipermail/ietf-dkim/2005q4/001306.html):

    1. Signature required/optional:
	sig=MUST/SHOULD/NEVER/USER (sig=STRONG/NEUTRAL/NEVER)
    2. 3rd parties allowed/not
	3ps=ALLOW/DENY/USER
	(Or if you like o=STRONG/3PS | o=NEUTRAL/NO3PS | o=USER/USER)

Hector Santos had several suggestions for additional values in the 3ps
space. (http://mipassoc.org/pipermail/ietf-dkim/2005q4/001318.html):

    signature=always, 3PS=IGNORE  -- Keep Original, don't strip, resign
    signature=always, 3PS=APPEND  -- Append, don't strip or replace.
    signature=always, 3PS=RESIGN  -- strip and replace.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Mar 2006 08:46:45 -0800

> -/STRONG	o=+signature,+3ps	signature=always,3ps=allowed

These tokens are related to use of a From email-address with a DKIM  
signature of the same domain.  Signature being optional while  
disallowing third-party signatures makes little sense.  The user  
level mode takes a high level of DNS transactions to a higher level  
while also exposing email-addresses.  If the mode restricts the use  
of From email-address to that of a DKIM signature of the same domain,  
there should be no need to indicate that no mail is sent.

With the use of specialized labels "*." for "open-ended" and "." for  
"only this domain" would allow the following meanings:

First-party signatures should include these domains and others.

_fps._dkim.<from-domain>. PTR this-domain.tld.
                           PTR that-domain.tld.
                           PTR *.

First-party signatures should only include this domain.

_fps._dkim.<from-domain>. PTR .

Key Group Tags provides a lower cost solution than a user level  
approach, and where annotation conventions could better protect  
recipients.

A PTR and Key Group Tag would allow for all these modes and yet  
provide better information.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Mon, 27 Mar 2006 22:46:41 +0000

> the messages was that we should use something that is even more meaningful.

One question Tony. Are you assuming that TXT will remain as the only
Policy/Practice retrieval mechanism? If a new RR is eventually
described, does that obviate the need to anglicize the current format?
Or does that depend on when "eventually" is?

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 27 Mar 2006 18:16:56 -0500

I make no assumption on the question of TXT versus other DNS RR's at
all. I view this topic to be totally orthogonal to the DNS question and
unrelated. I see having o=~ as difficult to remember, describe and use,
irrespective of what the DNS record looks like otherwise.

	Tony Hansen
	[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Mar 2006 17:03:25 -0800

On Mar 27, 2006, at 3:16 PM, Tony Hansen wrote:

> I make no assumption on the question of TXT versus other DNS RR's  
> at all. I view this topic to be totally orthogonal to the DNS  
> question and unrelated. I see having o=~ as difficult to remember,  
> describe and use, irrespective of what the DNS record looks like  
> otherwise.

An ability to recognize an email-address will become increasingly  
difficult once the EAI WG concludes.  Internationalization requires  
less reliance upon email-address recognition and more upon the  
signing-domain and key-groups.  Trust in the message content should  
be based upon both a restrictive key and the signing-domain.   
Associations between domains would be useful for message handling,  
which is not possible using these simple character flag or mnemonic  
assertions.

Establishing an association between various domains contained within  
the message and the DKIM signature would be better served using a  
domain name list (PTR RRsets).  By using syntax within a name list,  
the same types of character flag assertions are possible, but where  
more information is made available.  Rather than indicating some  
third-party signature should be acceptable, a specific list can be  
created to convey the same assertion, but where specific domains are  
listed.  This list could be a closed-ended list, where no other  
domains are directly associated with the From address.  This could  
also be expressed as an open-ended list.  The use of PTR RRs provides  
for name compression.  A new RR type would not have this ability.

Where it is common for ESPs to provide outbound mail service without  
restricting the From address, the lack of a restrictive key-group,  
such as "admin", could warn of a lack of assurance.  Annotations  
regarding what should be trustworthy should consider both the signing- 
domain and the key-group, where further assurances are established by  
making explicit domain associations.  This approach would allow the  
signing-domain to be different from the From email-address domain.   
The association would be an assurance offered by the email-address  
domain owner, much as the intent of the limited SSP assertions.

-Doug

---

From: "Mike Wolf" <[email-masked]>
Date: Mon, 27 Mar 2006 20:08:15 -0500

While on the topic of "o=", how about allowing a list of approved third
party signers to be included, rather than just declaring that either no
third party signing is allowed or everyone and their mother can sign on your
behalf?
This seems like an obvious improvement that could be backwards-compatible
with the current draft and would allow senders to explicitly enumerate those
third parties that are allowed to sign on their behalf.
If I am missing some other way to do this or there is some reason why this
makes no sense, just explain it to me.
- Mike Wolf

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Mar 2006 17:24:15 -0800

At 5:03 PM -0800 3/27/06, Douglas Otis wrote:
>difficult once the EAI WG concludes.

Nope. It will still be [email-masked]. There are more possible text 
characters on both sides of the @, but it will not be much harder 
than current email addresses with IDNs on the right side.

>   Internationalization requires less reliance upon email-address 
>recognition and more upon the signing-domain and key-groups.

That is a giant leap, one which few (if any) of the EAI participants 
have voiced so far.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2006 17:29:27 -0800

> Or does that depend on when "eventually" is?
Given that:

- There is only a small deployment of SSP records at this point
- There are good reasons for going to a new RR
- Unlike key records, there's no way to advertise whether to do a TXT or
"new RR" query for SSP

it seems like there are good reasons to accelerate the definition and
adoption a new RR for SSP.  In its most terse form, the "practices"
could mostly be defined as a number of independent, one-bit values.  In
any case, spending a lot of time on a definition that assumes TXT
records doesn't seem productive.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2006 17:37:28 -0800

Mike Wolf wrote:
> While on the topic of "o=", how about allowing a list of approved
> third party signers to be included, rather than just declaring that
> either no third party signing is allowed or everyone and their mother
> can sign on your behalf?
> This seems like an obvious improvement that could be
> backwards-compatible with the current draft and would allow senders to
> explicitly enumerate those third parties that are allowed to sign on
> their behalf.
> If I am missing some other way to do this or there is some reason why
> this makes no sense, just explain it to me.
> - Mike Wolf
>
One concern is that this doesn't scale.  I have heard one large
financial institution say that they have over 100 external senders of email.

Another concern is privacy; does a large corporation really want to
enumerate a list of its mailing partners?  It also makes the messages
sent by the external party less "seamless" (it looks more like an
external sender) and muddies the question of who is really responsible
for the message, the originating domain or the party sending messages on
their behalf.

The preferred way to do this is to publish a key record (selector) for
the external sender of email.  The external sender signs messages just
as if they were their client, and the client retains control of the
relationship by being able to revoke a key record at any time.

-Jim

---

From: <[email-masked]>
Date: Mon, 27 Mar 2006 20:39:02 -0500

Did you just pass the whitelisting chore to the name servers?
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Mon 3/27/2006 8:03 PM
To: Tony Hansen
Cc: [email-masked]
Subject: Re: [ietf-dkim] SSP and o= values

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 27 Mar 2006 20:49:40 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: <[email-masked]>

> records doesn't seem productive.

During MARID,  it is was my understanding that  non-active directory
versions of Microsoft DNS servers do no support the addition of new RR
records and during MARID this was one primary reason for sticking with TXT
(besides its obvious simplicity).

Is this correct?  If so, it is important?

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Mar 2006 18:02:00 -0800

On Mar 27, 2006, at 5:37 PM, Jim Fenton wrote:

>> third party signers to be included, rather than just declaring  
>> that either no third party signing is allowed or everyone and  
>> their mother can sign on your behalf?
>>
>> This seems like an obvious improvement that could be backwards- 
>> compatible with the current draft and would allow senders to  
>> explicitly enumerate those third parties that are allowed to sign  
>> on their behalf.
>>
>> If I am missing some other way to do this or there is some reason  
>> why this makes no sense, just explain it to me.
>

The email-address domain would be listing signing-domains.  A large  
institution should be able to delegate keys that extend to any number  
of external services.  For the average domain owner, the scale of a  
domain list will easily meet their needs.  Such a list already  
exceeds the capabilities of other types of email-registrations.

> enumerate a list of its mailing partners?  It also makes the  
> messages sent by the external party less "seamless" (it looks more  
> like an external sender) and muddies the question of who is really  
> responsible for the message, the originating domain or the party  
> sending messages on their behalf.

There is key delegation to hide who is doing the sending.  The  
signing-domain is _always_ accountable.  An association with a From  
email-address may change handling, as there would be less likelihood  
of the message being replayed.

> The preferred way to do this is to publish a key record (selector)  
> for the external sender of email.  The external sender signs  
> messages just as if they were their client, and the client retains  
> control of the relationship by being able to revoke a key record at  
> any time.

This type of intimate relationship is expensive for the average  
user.  The goal should be to ensure proper message handling does not  
require owning servers or needing special services.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Mar 2006 18:30:39 -0800

> than current email addresses with IDNs on the right side.

While it may still be text, this text may not be recognizable.  If  
displayed as a Unicode character, the repertoire in use may not be  
apparent.  When displayed as an encoded string, recognition then  
confronts limits of human perception.  Do you remember your car's  
license plate?  Encoded strings are equally opaque, as are Unicode  
presentations.

> That is a giant leap, one which few (if any) of the EAI  
> participants have voiced so far.

Why is establishing conventions for key-grouping and domain  
association lists a giant leap?  Why should any EAI participant be  
concerned about DKIM?  DKIM is still expected to handle ACE labels,  
which presents an equally difficult problem.  DKIM should be basing  
trust upon the signing-domain, where a subset of that domain should  
be able to receive trust-mark annotations on their messages.  (Don't  
expect anyone to recognize the email-address, after all few even see  
it.)  For those email-address domains wanting barriers placed on the  
use of their email-address domain, a domain association list would  
achieve a level of protection.  This protection could be available to  
the average user without special services or running their own  
servers.  It would also represent a single DNS transaction, but with  
far more information than found in an SSP RR.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2006 20:19:32 -0800

> Is this correct?  If so, it is important?
This is all hearsay, but what I hear is that this problem was corrected
in SP2.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 28 Mar 2006 02:28:48 -0500

----- Original Message -----

> This is all hearsay, but what I hear is that this problem was corrected

I just realize something....

Should we resolving Mike's non-standard DKIM compatability problem first?  I
mean, why bother to talking about RR and requiring specific Windows versions
if
it is going to cause problems with allman-01?

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2006 23:33:02 -0800

> it is going to cause problems with allman-01?

You're right that there is a relationship.  If we end up with an
incompatibility problem with allman-01 for some "good" reason, perhaps
it takes some of the pressure off the other compatibility issues.

-Jim

---

From: Graham Murray <[email-masked]>
Date: Tue, 28 Mar 2006 15:21:15 +0100

> financial institution say that they have over 100 external senders of email.

Which in the current climate of phishing is probably not a very
advisable for a financial institution to do.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 28 Mar 2006 06:53:48 -0800 (PST)

> (besides its obvious simplicity).

Not a primary reason. It so happens that good folks at Redmond also wrote
a firewall that does not just pass along dns requests but transforms them
into rpc calls and those are specific for each RR type with no easy way to
add new types. Microsoft DNS server appears to be capable of dealing with
new RR records as binary, but its not very easy to do or user-friendly.

Both of those products break standards in other ways, so in my view its 
not our concern that vendor decided to write incompatible code. Those
products are lot less used then most other products by same vendor and
those who use them do have a choice to use better products on the same OS.

---
William Leibzon
Elan Networks
[email-masked]