Subject: Re: [ietf-dkim] SSP - should we drop the cryptic o=. syntax for something a little more readable?

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Feb 2006 10:02:37 +0000

+2

And if we're changing, I'd prefer we not finalise a new syntax
until after we're done discussing the semantics we'd like.

S.

Tony Hansen wrote:
> +1
> 
> Mark Delany wrote:
>> Some history. SSP derived from DomainKeys policy. DomainKeys policy
>> derived from SPF as, at the time, there was some hope that SPF might
>> encompass DK-type systems so the syntax was made as compatible with
>> SPF as possible so it could just "slot in".
>>
>> Given that the "slot in" to SPF hasn't occurred in two years and SSP is
>> likely to now expand in a dimension different from SPF, maybe now is a
>> good time to dispense with the syntactic and cryptic comparability
>> goal and do something that's a little more human friendly.
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://dkim.org/ietf-list-rules.html
> 

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

---

From: Mark Delany <[email-masked]>
Date: Fri, 17 Feb 2006 06:48:53 +0000

On Fri, Feb 17, 2006 at 05:28:04AM +0100, Frank Ellermann allegedly wrote:

> You can also reinvent the wheel wrt "some text in DNS" for SSP,

No, that wheel has long existed. It's more about whether SSP should be
constrained to a byzantine syntax to encourage convergence.

Even in the most positive of circumstances the fit is a strain. After
all, most of SPF is about (resolution) mechanism, not policy. Whereas
all of SSP is about policy, not mechanism.

Furthermore, all indications are that folk here have plans for much
richer policy - such as "Check my reputation here" or "I'm accredited
there" and that seems not to be on the SPF radar.

Finally, history suggests that SPF isn't much interested in
convergence with DKIM.

The simple solution is to develop SSP as we see fit and, if at some
later stage it gets acknowledge by something like SPF, then SPF should
simply point to SSP along the lines of "redirect" rather than try and
constrain ourselves to SPF syntax and hope they adopt and embed it.

I don't expect that to be a burden for SPF - after all, they already
have syntax and logic to redirect and decode A records, redirect and
decode MX records, etc. To redirect and decode SSP is just another
variant.

Mark.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 10:04:27 +0100

Mark Delany wrote:

> It's more about whether SSP should be constrained to a
> byzantine syntax to encourage convergence.

| name "=" macro-string

Rather harmless, any visible character except from "%", and
to get a literal "%" you'd say "%%".  The byzantine part is
limited to anything else starting with "%".

> the fit is a strain.

Yes.  Talk about less than 100 characters, and I'd say "go",
if you want much more better stay away from SPF modifiers.

> most of SPF is about (resolution) mechanism, not policy.
> Whereas all of SSP is about policy, not mechanism.

In SPF terminology mechanisms are also "policy".  Different
ways to enumerate all IPs combined with "pass", "dunno", "fail"
qualifiers.  For some ways your "byzantine" and my "baroque"
might be identical... :-)

> Furthermore, all indications are that folk here have plans
> for much richer policy - such as "Check my reputation here"
> or "I'm accredited there" and that seems not to be on the
> SPF radar.

"We" (SPF) had the same discussions, folks inventing wild and
wonderful new modifiers, but nothing got real traction.  Phil,
William, and I went so far to put something into I-D format.
But if no implementor makes noises to support any of these
ideas it's pointless.

Whatever you do, don't try any "XML over DNS".  Just don't.

> Finally, history suggests that SPF isn't much interested
> in convergence with DKIM.

Not sure what you're talking about.  SES ?  Meta ?  SPF is
very strict about its focus on 2821, and DKIM is apparently
strict about its focus on 2822.  That could be a fit as far
as I'm concerned.

SenderID is of course a different matter.  Like STRONG DKIM
also addressing "phishing", and using 2822.  Unless you have
ideas for the first "positional modifier" it's the same SPF
syntax, otherwise it's minimally more byzantine than v=spf1.

> The simple solution is to develop SSP as we see fit and, if
> at some later stage it gets acknowledge by something like
> SPF, then SPF should simply point to SSP along the lines of
> "redirect"

Okay, for anything that's more interesting than YES or NO the
best way to get around size issues.  The byzantine "exp" is
a better example for that purpose, "redirect" is too special.

> rather than try and constrain ourselves to SPF syntax and
> hope they adopt and embed it.

The "they" would be implementors, SPF or SSP isn't the point.

You're perfectly free to publish drafts with new SPF modifiers
if that's the most simple solution for a problem you want to
solve.  If it gets out of hand we'd need a proper IANA registry
for modifiers, but that's only a formality.

If an implementor would tell me that he really likes op=auth
(for reputation) or op=pra I could submit the draft within an
hour, it's ready.  That didn't happen for more than a year.

And op=pra could make perfect sense in the situation as it is,
telling the same story twice (in spf2.0/pra,mfrom and v=spf1)
is stupid wrt UDP size issues, one "v=spf1 op=pra" is shorter.

> To redirect and decode SSP is just another variant.

True, but it would only work for systems supporting SPF and
DKIM.  For systems supporting only DKIM you need some well
known place in DNS derived from a domain relevant for DKIM -
that's probably not what you find in the MAIL FROM.  Maybe
the HELO is more interesting wrt reputation.

If that's supposed to work for systems only supporting DKIM
but not SPF, then a simple flag in the sender policy instead
of a redirection could be good enough:

yes: it makes sense to query well known DKIM place for more
no : don't bother to query, I don't support this DKIK stuff

The dkim=strong idea is similar, "don't bother to check SSP
for _this_ domain, it has a STRONG DKIM signing policy".

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 05:28:04 +0100

Mark Delany wrote:

> Given that the "slot in" to SPF hasn't occurred in two years
> and SSP is likely to now expand in a dimension different from
> SPF, maybe now is a good time to dispense with the syntactic
> and cryptic comparability goal and do something that's a
> little more human friendly.

If all you need from SPF are some modifiers feel free to use
it.  The constraints are clear, a single SPF record is limited
in its size by UDP, "keep it short" is a necessity.  But not
beyond recognition, some weeks ago Wayne posted something here
about the too terse SSP notation.

You can also reinvent the wheel wrt "some text in DNS" for SSP,
Phil had some interesting proposals how to do that better than
SPF did (avoiding "yet another DNS text RR" issues).  Wayne had
another idea, "DNS text RRs for everybody".  Somebody would
have to fight it out on namedroppers, please don't count me in.

At the moment I see a good way to get some kind of dkim=strong
or op=dkim accelerator in SPF indicating a STRONG DKIM SSP for
receivers supporting both SPF and DKIM.

If that would be all that SSP really does, either STRONG or
not, then reinventing the wheel might be a waste of time, just
specify it as SPF modifier and be done with it.

OTOH if DKIM somehow gets into a situation where supporting a
minimal part of SPF is "required" to get DKIM right it, then
we'd need "downref", the CLEAR-folks would be probably upset,
and I'd really prefer it if DKIM makes sense without SPF, and
vice versa.  The fine print "DKIM is strong where SPF is weak,
SPF is strong where DKIM is weak" should be obvious without
spelling it out in the form of any normative reference.  Bye

---

From: Tony Hansen <[email-masked]>
Date: Thu, 16 Feb 2006 22:00:16 -0500

+1

---

From: Mark Delany <[email-masked]>
Date: Fri, 17 Feb 2006 02:08:37 +0000

Mark.

---

From: Eric Allman <[email-masked]>
Date: Fri, 17 Feb 2006 06:12:41 -0800

+3.  I always have to look the damned things up.

eric

---

From: Michael Thomas <[email-masked]>
Date: Fri, 17 Feb 2006 06:38:58 -0800

> +3.  I always have to look the damned things up.

Oh goody, I get to be a contrarian!

-1

For two reasons:

1) With my developers hat on, I couldn't really care the least:
    if you have to look them up, you probably need to look up the
    other single character tags too. This is just a matter of being
    familiar with the spec, and h, z, b, m etc are all equally
    opaque IMO.

2) I'm guessing that we will utterly fail to have a single word that
    describes the rich semeantics of the policy attached to whatever
    symbol we choose. Witness this latest brouhaha with "exclusive"
    which is not even part of the current draft. An abstract symbol
    which has no baggage of its own and is, in fact, just a pointer
    to the normative text seems like a better way to avoid
    misinterpretation.

		Mike

---

From: Eric Allman <[email-masked]>
Date: Fri, 17 Feb 2006 07:17:44 -0800

> Oh goody, I get to be a contrarian!

Mike, I would have been severely disappointed if you weren't a 
contrarian.

>     familiar with the spec, and h, z, b, m etc are all equally

Good point, but I still find (most of) the letters to be more 
mnemonic than characters such as "-", "~", and "!", all of which mean 
"not" to me.

>     to the normative text seems like a better way to avoid

I have to admit that this is a good point.

eric

---

From: Michael Thomas <[email-masked]>
Date: Fri, 17 Feb 2006 07:38:47 -0800

Eric Allman wrote:
> Mike, I would have been severely disappointed if you weren't a contrarian.
> 
>> For two reasons:
>>
> Good point, but I still find (most of) the letters to be more mnemonic 
> than characters such as "-", "~", and "!", all of which mean "not" to me.

Not to belabor this too much, but even in my example above, I got
m(ethod) wrong for q(uery)...

> I have to admit that this is a good point.

One other thing I wanted to mention: at this point I'm a lot more
concerned about the semantics than the syntax. That is, we've never
even really come to any consensus that the current crop of policies
are actually the right ones, and I'm generally concerned that we
need to understand how what is currently described as the "testing"
axis relates to the current "policy" axis... and whether those two
axes needed, sufficient and/or correct.

		Mike

---

From: Tony Hansen <[email-masked]>
Date: Fri, 17 Feb 2006 10:56:32 -0500

Who said that we'd have to replace the current single character tags
with other single character tags?

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]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 17 Feb 2006 10:13:30 -0800 (PST)

Just note to start with that current SSP syntax is not really compatible
with SPF on the protocol level. It just uses some of the same symbols that
have special meaning in SPF, but the way they are used (policy=symbol) is 
very different then spf where symbol is prefix for mechanisms. The 
"policy=symbol" is ok with SPF as a modifier but modifiers are not treated 
same way as mechanisms and need not use any kind of special symbol (so for 
example for meta signatures which is using SPF as policy record, the 
modifier has text as a value i.e. "metasig.sender=required").

On Fri, 17 Feb 2006, Mark Delany wrote:

> richer policy - such as "Check my reputation here"

"Check my reputation here" is not appropriate policy. Anything the
sender says including where to look is accreditation info.

> or "I'm accredited there" and that seems not to be on the SPF radar.

I do not see it happening for crypto either if systems check SSP only in 
case signature does not match address in From field.

On the other hand SPF is checked for every message and it as well suited 
to accreditation info with SPF modifiers as as SSP is - the syntax is also 
likely to be the same (spf modifiers are basically freeform name=value data).

> decode MX records, etc. To redirect and decode SSP is just another

It would require new version of SPF for it to understand some new type
of record, nor do I see redirect ever being used in the way you suggest.
(and it does seem that you're not well versed in how SPF works based on 
how you describe it above).

Now as far as SPF use of crypto signature data, assuming the signature
is based on the identity address that is found in Envelope From that
could be of use. But in that case the SPF record would be the one to 
provide policy information about its use anyway not some other record
as SSP by current drafts is for use with From header field.

My suggestion however (just in case) is to have "scope" included in SSP
as part of its syntax - so it could be used for other things and without
the kind of problems SPF has experienced because of old decision to not
include scope in late 2003 drafts that sparked active development.

BTW - If you do want to have certain compatibilities with SPF than all
you really need to do is keep "name=value" tag system (and also include
v=?? as prefix).

-- 
William Leibzon
Elan Networks
[email-masked]