Subject: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 13:07:50 -0800

The current assumption used when asserting DKIM policy is that this  
policy might apply across _all_ protocols used to carry messages that  
might contain DKIM signatures.  Either DKIM policy records need to  
declare the scope of the protocols covered by the policy, or the label  
used to discover a policy should employ different labels.

Add:

Policy assertions for _SSP records are limited to messages exchanged  
by SMTP.  When other protocols are used to receive messages, the  
appropriate policy should be applied upon receipt, and/or the protocol  
should be tracked within the message.  One method for such tracking  
could be implemented using Authenticated-Results headers.

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

---

From: [email-masked] (Wietse Venema)
Date: Wed, 13 Feb 2008 16:32:51 -0500 (EST)

> could be implemented using Authenticated-Results headers.

Excuse my ignorance, but why limit DKIM (or SSP) to information
that is delivered via SMTP? They can work with any transport that
uses RFCx822 for content and that uses DNS for name resolution.

	Wietse

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 13 Feb 2008 16:54:11 -0500

>
>Excuse my ignorance, but why limit DKIM (or SSP) to 
>information that is delivered via SMTP? They can work with any 
>transport that uses RFCx822 for content and that uses DNS for 
>name resolution.
>
>

+1

---

From: [email-masked] (Wietse Venema)
Date: Wed, 13 Feb 2008 17:00:00 -0500 (EST)

> uses RFCx822 for content and that uses DNS for name resolution.

-1 for the updated proposal.  Cosmetic surgery on a dead horse
won't bring it back to life.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Feb 2008 14:27:21 -0800

> uses RFCx822 for content and that uses DNS for name resolution.

   What I'd like to know is how we implement the electric chair for
   violators of this prohibition.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 14:46:10 -0800

On Feb 13, 2008, at 1:32 PM, Wietse Venema wrote:

>> policy might apply across _all_ protocols used to carry messages  
>> that might contain DKIM signatures.  Either DKIM policy records  
>> need to declare the scope of the protocols covered by the policy,  
>> or the label used to discover a policy should employ different  
>> labels.
>>
>> Add:
>>
>> Policy assertions for _SSP records are limited to messages  
>> exchanged by SMTP.  When other protocols are used to receive  
>> messages, the appropriate policy should be applied upon receipt,  
>> and/or the protocol should be tracked within the message.  One  
>> method for such tracking could be implemented using Authenticated- 
>> Results headers.
>
> Excuse my ignorance, but why limit DKIM (or SSP) to information that  
> is delivered via SMTP? They can work with any transport that uses  
> RFCx822 for content and that uses DNS for name resolution.

Agreed.  DKIM can be employed in conjunction with _many_ transport  
protocols.  While a domain may assert they sign "all" their SMTP  
traffic, they may not be signing other types of traffic that could  
potentially use DKIM signature headers.  How would a domain indicate  
what protocol they cover by their assertion?  It seems logical to  
restrict the _SSP policy to that of SMTP.  Other protocols can define  
where the relevant policy can be found, or they could add a protocol  
policy scope to the record.

The policy should make it clear when it applies to SMTP.  When there  
is also a mandate to publish an MX record while publishing SMTP  
policy, the the following states will have been defined:

SMTP          SMTP/DKIM
DISCOVERY     POLICY
(MX)          (SSP)     State

  NO		NO	0 Status Quo
  YES		NO      1 No Policy Defined
  NO		YES	2 SMTP Disavowed (cease further transactions)
  YES		YES	3 Policy Defined (SMTP/DKIM supported)

For example, when "non-smtp-domain.sld.tld" publishes a SMTP/DKIM  
policy without an MX record resulting in state 2, this halts a  
discovery process from making SSP record queries against "sld", and  
could prevent bogus key record queries from being made against "non- 
smtp-domain.sld.tld".  Being able to disavow having sent a message  
while also curbing some DNS related traffic should provide an  
incentive for domains to publish SMTP/DKIM policy record.  As  
currently defined, only state 2 offers a clear indication of a message  
being disavowed or repudiated.  This repudiation should be even  
stronger evidence than that obtained with an invalid signature.  Those  
that fail to publish MX records in conjunction with SSP policy records  
might find some verifiers consider their SMTP traffic as having been  
disavowed.  This would also be an incentive to publish.

Providing incentives for domains that don't use email to publish  
policy records ensures greater value in bothering to query for the  
record in the first place.  The juice being worth the squeeze.

-Doug

---

From: [email-masked]
Date: Wed, 13 Feb 2008 15:19:40 -0800

>   violators of this prohibition.

They might be handicapped, but I really don't think we should go out of our way, 
like that, to improve their mobility...

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: Wed, 13 Feb 2008 15:33:54 -0800

> uses RFCx822 for content and that uses DNS for name resolution.

Interesting idea.  In 4871, we do have the s= tag and the DKIM Service 
Types registry.  Perhaps SSP should specify which service type(s) to 
which the record applies; for completeness we should probably have a way 
of specifying multiple (service type, policy) groups, although the only 
service type in the registry now is "email".

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 15:48:17 -0800

On Feb 13, 2008, at 3:33 PM, Jim Fenton wrote:

> Interesting idea.  In 4871, we do have the s= tag and the DKIM  
> Service Types registry.  Perhaps SSP should specify which service  
> type(s) to which the record applies; for completeness we should  
> probably have a way of specifying multiple (service type, policy)  
> groups, although the only service type in the registry now is "email".

Jim,

The service type that could be noted in the key does will not work as  
there are no defined key locations.  The policy scope needs to be  
within the policy record or reflected in the label used to locate the  
record.

Depending upon the label works well, but then there might be a desire  
to signal "cease and desist" when there are multiple policies.   The  
"cease and desist" state can be generally defined as the presence of  
the policy record with the absence of the discovery record.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 14 Feb 2008 00:53:13 +0100

> potentially use DKIM signature headers.  How would a domain 
> indicate what protocol they cover by their assertion?  It seems
> logical to restrict the _SSP policy to that of SMTP.

IBTD.  The From: header field you see in this reply was originally
posted with NNTP at GMaNe, and GMaNe sent it to the "moderator" of
"the DKIM newsgroups", which is actually the DKIM list at mipassoc,
a somewhat convoluted case of news2mail (and back again, from my
POV).  

Less convoluted, a "real" newsgroup can contain news2mail gateways
resulting in real SMTP traffic.  Still with the original 2822 From
address(es).  Those are only obvious examples - adding transport 
protocol "scopes" cannot work when gateways transform "something"
(news, MMS, etc.) into ordinary mail with an SSP protected From.

Let's note the issue in the security considerations.  The official
title of 2822 is "Internet *message* format", not only *mail*.  An
2822-From is no "mail-From" or "news-From", it is for all messages.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Feb 2008 15:58:13 -0800

> within the policy record or reflected in the label used to locate the 

I'm not depending on the key; I'm simply noting that since there is 
extensibility of DKIM signatures beyond SMTP and that it may be 
desirable to have similar extensibility of SSP.
> the policy record with the absence of the discovery record.

I don't know what a "discovery record" is.  Why can't the practices for 
these other services be located at the same place?  It seems unlikely 
that we will ever have that many services using RFCx822 for content that 
we'll run out of record space.  Feel free to quote me widely when I'm 
wrong about that.

-Jim

---

From: SM <[email-masked]>
Date: Wed, 13 Feb 2008 16:43:18 -0800

>groups, although the only service type in the registry now is "email".

DKIM is also referenced in SIP.  To make room for a service type, you 
could have a record such as email._ssp._domainkey.example.com.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 16:54:49 -0800

On Feb 13, 2008, at 3:58 PM, Jim Fenton wrote:
> Douglas Otis wrote:
>>
>> Jim,
>>
>> The service type that could be noted in the key does will not work  
>> as there are no defined key locations.  The policy scope needs to  
>> be within the policy record or reflected in the label used to  
>> locate the record.
>

Understood, but this does not help much.  This does not prevent  
negatively rating unsigned messages traversing a protocol not covered  
by the DKIM policy assertion.  It may also be that new protocols will  
also introduce use of DKIM policies.  When messages are being merged  
by various protocol gateways, the correct policy should be applied at  
the point of ingress.  A restriction on the SSP record as being  
limited to SMTP may mean messages emerging from this mailing-list  
could become non-compliant with a From domain's "all" assertion.  This  
non-compliance might be forgiven by a mailing-lists favourable DKIM  
signature rating, and the policy would not be applied against the non- 
SMTP protocol.

>> Depending upon the label works well, but then there might be a  
>> desire to signal "cease and desist" when there are multiple  
>> policies.   The "cease and desist" state can be generally defined  
>> as the presence of the policy record with the absence of the  
>> discovery record.
>
> I don't know what a "discovery record" is.

The discovery record is how the transmitter discovers the receiver.   
In the case of SMTP, this can be defined as being an MX record when  
policy is published.

> Why can't the practices for these other services be located at the  
> same place?

Domains are unlikely to apply DKIM in all possible places at once.   
Conflicting assertions may therefore result when not scoping the  
protocol coverage of the policy record.

>  It seems unlikely that we will ever have that many services using  
> RFCx822 for content that we'll run out of record space.

You mean space to scope protocols within the policy record?  Agreed,  
and assuming a default scope of SMTP also seems appropriate.  Using  
different labels rather than a scope parameter providers greater  
flexibility.  The protocol used to accept the message should be known  
by the verifier.  (See authenticated-results header.)

>  Feel free to quote me widely when I'm wrong about that.

It might be good to scope protocols within the key as well, but  
frankly that seems less of a problem.  You can quote me as well. : )

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Feb 2008 11:26:18 -0000

> policy scope to the record.

If you want to indicate that information, then propose a new tag within  
the SSP record for the purpose. But the default should be that the SSP  
applies to all modes of transport. Otherwise the Bad Guys will just send  
mail like the following:

Received: by bar.com from foo.com by SMTP ...
Received: by foo.com from ebay.com by UUCP ...
From: [email-masked]
[NO DKIM signature]

And the verifier would note (after a lot of trouble) that the message  
originator sent it by UUCP, and hence the absence of a Signature was to be  
expected, in spite of the ferociously strict policy bublished by ebay.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 14 Feb 2008 11:08:41 -0800

On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote:

> On Wed, 13 Feb 2008 22:46:10 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>> logical to restrict the _SSP policy to that of SMTP.  Other  
>> protocols can define where the relevant policy can be found, or  
>> they could add a protocol policy scope to the record.
>
> If you want to indicate that information, then propose a new tag  
> within the SSP record for the purpose. But the default should be  
> that the SSP applies to all modes of transport. Otherwise the Bad  
> Guys will just send mail like the following:
>

Agreed.  This issue does not appear to have been entered into the RT  
tracking, but both you and Jim have suggested this alternative  
solution.  Here is a more formalized suggestion for a tag added to the  
policy record.

s= Policy Scope (plain-text; OPTIONAL; default is "SMTP").  A colon-
    separated list of policy scopes specify which protocols to which
    this record applies.  Verifiers for a given service type MUST
    ignore this record if the appropriate type is not listed.
    Currently defined service types  are as follows:

        *   matches all service types
        !  disavows protocol use

        SMTP	RFC2821
        NNTP	RFC3977
        MSRP	RFC4975

    This tag is intended to constrain the use of policy for various
    transport protocols that may implement, should DKIM be defined by
    other protocols in the future. This tag can also disavow use
    of specific protocols to repudiate references to this domain.

ABNF:

    policy-s-tag  = %x73 [FWS] "=" [FWS] [proto-disavow] policy-s-tag- 
type
                        0*( [FWS] ":" [FWS] policy-s-tag-type )
    proto-disavow = "!"
    policy-s-tag-type   = "SMTP" / "NNTP" / "MSRP" / "*" / x-policy-s- 
tag-type
    x-policy-s-tag-type = hyphenated-word   ; for future extension

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Feb 2008 12:50:53 -0000

On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <[email-masked]>  
wrote:

>> applies to all modes of transport. Otherwise the Bad Guys will just  
>> send mail like the following:
>>

No! The default must be '*'.
>     of specific protocols to repudiate references to this domain.

But you have to make it clear that verifiers can only discern the protocol  
used by the originating site by carefull examination of Received headers  
(and believable ones at that). So I am still very dubious about adding  
this feature.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Feb 2008 11:27:29 -0800

On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote:

> On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>> Agreed.  This issue does not appear to have been entered into the  
>> RT tracking, but both you and Jim have suggested this alternative  
>> solution.  Here is a more formalized suggestion for a tag added to  
>> the policy record.
>>

The concern regarding defaults was addressed in Take #3.  This version  
includes a means to exclude policy.

    *  matches against all unlisted transport protocols
    !  disavows protocol use
    -  excludes protocol from policy assertions

I suspect the default should be "s=SMTP" where this would be the same  
as "s=SMTP:-*".  When the domain exchanges no communication  
whatsoever, "s=!*" could be used.  When only SMTP messages are used,  
then "s=SMTP:!*" would make this assertion.

> But you have to make it clear that verifiers can only discern the  
> protocol used by the originating site by carefull examination of  
> Received headers (and believable ones at that). So I am still very  
> dubious about adding this feature.

Trace headers can not be included within DKIM signatures.  This  
limitation means DKIM policy applied against messages arriving over  
SMTP may affect messages passing though third-party protocol gateways  
bridging other protocols into SMTP.   When messages arrive over  
different protocols within the same administrative domain,  
Authentication-Results headers could be used to indicate which  
protocol transmitted the message into the administrative domain, where  
these messages are placed into a common mailbox.  It would be wrong to  
assume this is always the case.

See:
http://www3.tools.ietf.org/html/draft-kucherawy-sender-auth-header-11

The significant value in the Authentication-Results header is that it  
can be filtered at border MTAs.  By adding a ptype of  
"Transport=<protocol>" to this header, a gateway can thereby indicate  
which transport protocol introduced the message.  Unless this  
information is conveyed to the recipient by some mechanism when the  
mailbox normally serves as a repository SMTP messages, it would be  
better to apply policy that pertains to SMTP.  This may mean a DKIM  
policy of "all" may cause some third-party gateway related messages to  
be refused or placed within a different folder as a result.

A policy scope mechanism allows other transports to apply policy in  
accordance with the domains assertion of protocol support, and whether  
the DKIM specific assertion should be applied.  As such, an a DKIM/ 
SMTP policy of "all" would not affect messages sent over NNTP with a  
policy scope of "s=SMTP" for example.  As other forms of message  
exchange implement DKIM, the scope of DKIM specific policies  
assertions becomes more critical.  When the NTTP message is translated  
into message carried by SMTP, then SMTP policy may negatively affect  
the categorization of the NNTP message when these are not being signed.

This WG is largely comprised of those primarily focused upon SMTP.  As  
such, DKIM policy is being considered only from the aspect of SMTP.   
While DKIM could be implemented by other types x822 message exchange,  
few would expect all of these communications to simultaneously  
implement DKIM.  There are a few choices to resolve this potential  
issue.

a) Stipulate the *SP policy record applies to messages arriving over  
SMTP (require different policy domain labels for each protocol).

b) Provide a scope parameter within the policy record.

 From a maintenance and overhead standpoint, option "b" could be the  
best solution.  In Take #3, to make this friendly to gateways change:

When a protocol has been disavowed, any further DKIM related  
transactions should cease.

with:

When all protocols has been disavowed, any further DKIM related  
transactions should cease.

This last statement provides a means to protect specific domains and  
their parent domain from an inordinate amount of DNS traffic when an  
existing domain is spoofed in a spam campaign.  The policy scope  
parameter allows other types of message spoofing to be mitigated with  
as DKIM becomes implemented for each respective transport.  The fact  
that a protocol can be bridged into SMTP should not inhibit the use of  
"all" for SMTP, or for other protocols to assume that "all" only  
applies to SMTP.  For DKIM to offer it greatest protections, a means  
to scope the policy is essential.  Pick "a" or "b".

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Feb 2008 11:41:16 -0000

> includes a means to exclude policy.

And indeed Take #3 starts:

s= Policy Scope (plain-text; OPTIONAL; default is "*").

so it seems my point is accepted.
> I suspect the default should be "s=SMTP" where this would be the same as  
> "s=SMTP:-*".  When the domain exchanges no communication whatsoever,  
> "s=!*" could be used.  When only SMTP messages are used, then  
> "s=SMTP:!*" would make this assertion.

But now you are contradicting yourself. First you say 'default is "*"';  
now you are saying 'I suspect the default should be "s=SMTP"'. Which is it?

> Trace headers can not be included within DKIM signatures.

Then in that case the whole idea of a protocol parameter in SSP falls flat  
on its face. Because there is no other method, apart from Received  
headers, for telling what was the original protocol used in sending the  
message, and we all know how easy Received headers are to spoof.

So we are back to what Hector is saying. SSP MUST be applicable to any  
message in RFC 2822 format, or any format similar to that (which clearly  
includes News). Because other formats are regularly gated _into_ SMTP  
(often with the removal of headers such as Newsgroups and Path which might  
have indicated their origin). So sites that publish  
strict/discardable/whatever policies will just have to be careful.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Feb 2008 10:30:53 -0800

On Feb 20, 2008, at 3:41 AM, Charles Lindsey wrote:

>>> On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <[email-masked] 
>>> >
>>> wrote:
>
>> The concern regarding defaults was addressed in Take #3.  This  
>> version includes a means to exclude policy.
>
>> I suspect the default should be "s=SMTP" where this would be the  
>> same as "s=SMTP:-*".  When the domain exchanges no communication  
>> whatsoever, "s=!*" could be used.  When only SMTP messages are  
>> used, then "s=SMTP:!*" would make this assertion.
>

The policy assertion of "s=*", this would mean that other protocols  
might be affected the publisher did not expect.  Rather than  
potentially blocking other protocols, an assertion of "s=SMTP", as a  
default, would require publishers to proactively make explicit  
restrictions on other protocols.  From the comments on this list, it  
seems most view the policy record as being related to messages  
entering the SMTP related infrastructure.   In that respect, the SMTP  
policy would be applied anyway.  Having this policy record impact  
fully independent and separate message transports seems as though it  
should be explicit.  Having an explicit policy will also allow the  
verifier to better trust that this restriction was the intent of the  
policy.  Trust in assertion is important.

> Then in that case the whole idea of a protocol parameter in SSP  
> falls flat on its face. Because there is no other method, apart from  
> Received headers, for telling what was the original protocol used in  
> sending the message, and we all know how easy Received headers are  
> to spoof.

Type of transport is always implied.  Messages handled primarily by  
SMTP transport, you would be absolutely right, SMTP is the only  
assumption that should be made.  DKIM can also be used by independent  
and separate message transports protocols that are completely  
unrelated to SMTP.  In that case, the transport is also implied, but  
it would not be SMTP.

> So we are back to what Hector is saying. SSP MUST be applicable to  
> any message in RFC 2822 format, or any format similar to that (which  
> clearly includes News). Because other formats are regularly gated  
> _into_ SMTP (often with the removal of headers such as Newsgroups  
> and Path which might have indicated their origin). So sites that  
> publish strict/discardable/whatever policies will just have to be  
> careful.

If this view prevails, then the *SP should be defined as being  
applicable to SMTP related messages, which includes any other  
protocols that might be delivered to the same location as those  
carried over SMTP.

-Doug

-

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Feb 2008 12:01:35 -0000

> policy.  Trust in assertion is important.

And after all that waffle, you still have not answered the question. Are  
you proposing the default is "s=*" or are you proposing the default  
"s=SMTP" (since your message seemed to be proposing both).

But as for publishers of SSP records, the stricter the policy they  
declare, the more careful they must be that users of their domain, are not  
able to bypass the signing mechanism by using strange protocols/whatever.  
How they do that is their problem. So if they publish "s=*" (or if that is  
the default), then they are saying that if anything arrives looking like  
an RFC 2822 message from our dopmain, but unsigned, then you should  
reject/discard/suspect/whatever it.

But if they publish "s=SMTP" and something leaves their domain via  
UUCP/NNTP/whatever-else, then they are syaing it is OK not to be signed.  
But then it it gets gatewayed back into SMTP, verifiers may not be able to  
tell that it was not SMTP originally, and so will still  
reject/discard/suspect/whatever it.

Or if you intend that the "s=SMTP" is to be avaluated according to the  
protocol by which it was received by the verifier, then it will still be  
rejected/whatever, even though it legitimately left the original domain  
unsigned via UUCP/NNTP; is the gateway supposed not to have gatewayed it  
in that situation. All you have created then is a glorious opportunity for  
everyone to blame everyone else for preventing the mail from being  
delivered.

In short, the only thing which will work in the face of gatewaying of any  
sort is to say that SSP applies to anything looking like an RFC 2822  
object, in which case you don't need an "s=" tag at all.

> unrelated to SMTP.  In that case, the transport is also implied, but

And just what is all that supposed to mean?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Feb 2008 17:00:47 -0800

> And after all that waffle, you still have not answered the question.  
> Are you proposing the default is "s=*" or are you proposing the  
> default "s=SMTP" (since your message seemed to be proposing both).

The change in defaults was to meet your requested default.  From your  
comments, it would seem you view the policy scope statement  
differently from what was intended.  The view that SSP policy records  
only pertain to SMTP related infrastructure, which includes messages  
introduced into this infrastructure, would also be acceptable (When  
disavow can be confirmed of course).  There are other message  
transports able to operate independently from SMTP and yet utilize  
DKIM.  It would help reduce DNS overhead combining DKIM policy records  
for various independent protocols into a single record, while also  
limiting exposure to abuse otherwise sent over disavowed transports.

Policy scope would permit fully independent protocols a means to  
assert both protocol support and the application of DKIM policy  
against the protocol.  This scope statement could thereby block  
possible vectors of abuse.  The policy scope would provide an  
incentive for domains not implementing DKIM to assert a policy scope  
just to disavow use of a protocol at an existing domain to mitigate  
traffic that distributed spoofing might otherwise create.

The scope parameter offers three states:

1) Status Quo,

2) DKIM policy Applies to the specific transport protocol carrying the  
message,

3) Transport Protocol Disavowed.

In the case of another protocols bridged into SMTP, the policy defined  
for SMTP would apply.  The policy scope does not refer to transports  
being bridged into SMTP, expect at the bridge when the transport  
itself has been disavowed.

> declare, the more careful they must be that users of their domain,  
> are not able to bypass the signing mechanism by using strange  
> protocols/whatever.  How they do that is their problem. So if they  
> publish "s=*" (or if that is the default), then they are saying that  
> if anything arrives looking like an RFC 2822 message from our  
> dopmain, but unsigned, then you should reject/discard/suspect/ 
> whatever it.

Agreed.  But requiring an explicit restriction would minimize the  
number of domains astonished by the impact of the policy.  When too  
many make a mistake using the default, then the default assertion has  
little meaning.  As such, in the long run, it would be safer to  
require restrictions for other protocols be expressed explicitly.

> UUCP/NNTP/whatever-else, then they are saying it is OK not to be  
> signed.

When messages enter into infrastructure supporting messages normally  
carried by SMTP, then the policy defined for SMTP should be used.   
This may block messages from other transports integrated into SMTP  
related infrastructure.  When NTTP messages never touch SMTP  
infrastructure, and the policy scope is s=SMTP, then NTTP messages are  
excluded from assertions of being signed.  This default would create  
less astonishment, and not affect NTTP messages that are handled  
separately from those related to SMTP.

>  But then it it gets gatewayed back into SMTP, verifiers may not be  
> able to tell that it was not SMTP originally, and so will still  

Yes.  When a message is carried over SMTP, there is nothing  
differentiating the messages from the perspective of the recipient.

When the recipient uses a different client for different transports,  
or when messages carried over different transports are delivered to a  
different location, then explicitly indicating whether messages for a  
particular transport are "all" signed would be highly beneficial.

> Or if you intend that the "s=SMTP" is to be evaluated according to  
> the protocol by which it was received by the verifier, then it will  
> still be rejected/whatever, even though it legitimately left the  
> original domain unsigned via UUCP/NNTP;

When the domain also signs all messages carried by NNTP, then the  
policy scope could be "s=SMTP:NTTP dkim=all".  When it does not, then  
"s=SMTP dkim=all" would accurately reflect that situation.  When scope  
is introduced after SSP is initially published, the scope default will  
need to be "s=SMTP".

> is the gateway supposed not to have gatewayed it in that situation.  
> All you have created then is a glorious opportunity for everyone to  
> blame everyone else for preventing the mail from being delivered.

When protocol bridging is done internal to the administrative domain,  
then Authentication-Results headers with the parameter Transport=<>  
added could allow each message type to be handled properly and perhaps  
delivered to a separate folder.  DKIM in conjunction with SSP policy  
may cause some of these protocol bridged messages to become blocked.   
This is unavoidable.  The policy scope would provide a means for this  
problem to handled according to the assertions of the signing domain.

> In short, the only thing which will work in the face of gatewaying  
> of any sort is to say that SSP applies to anything looking like an  
> RFC 2822 object, in which case you don't need an "s=" tag at all.

This would be assuming independent protocol transports are not using  
DKIM.  When different protocols are bridged into SMTP, of course  
"s=SMTP" policy scope can be assumed.

>> assumption that should be made.  DKIM can also be used by  
>> independent and separate message transports protocols that are  
>> completely unrelated to SMTP.  In that case, the transport is also  
>> implied, but it would not be SMTP.
>

Messages received by your IM client may implement DKIM over a  
transport protocol unrelated to SMTP, where its messages are not  
destine for a location also receiving messages carried by SMTP.  At  
some point in the future, the signing domain may wish to include more  
than just SMTP within their assertion as to which messages are being  
signed.  As it is now, SSP policy MUST BE assumed to apply to those  
messages related to the SMTP infrastructure.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 Feb 2008 13:00:53 -0000

> separately from those related to SMTP.

I can think of nothing more astonishing to the readers of some newsgroup  
and of its associated mailing lists that to have some messages propagating  
freely within the newsgroup but not being visible within the mailing list.

The more you try to justify this "s=" tag, the deeper into the pit you dig  
yourself. It is evident to me that the whole idea is utterly indefensible.

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 22 Feb 2008 14:53:30 +0100

Charles Lindsey wrote:

> It is evident to me that the whole idea is utterly indefensible.

+1  It's a real issue, but *doumenting* it instead of *fixing* it
with obscure scopes suffices for now.  Gateway operators need to
know it, e.g., GMaNe could educate its users in its FAQ.

In addition to the domain owners intending to introduce some kind
of strict/reject/discard/whatever *SP, they first have to educate
their users.  And maybe folks like you have to do something with
their mail2news solutions if they want SSP protection.

Later, if say NNTP introduces a variant of DKIM in addition to
"pgpverify" for its purposes, a document explaining NNTP-DKIM
can say what NNTP-*SP is supposed to be, if anything at all.

Based on SPF experiences:
1 - Whenever "scopes" were discussed on the SPF list it ended up
    in 2822-ratholes.
2 - The number of popular "SPF extensions" (modifiers including
    ways to emulate "scopes" with modifiers) after four years is
    *zero*.  By a stretch of fantasy I can defend op=auth, but
    that's all after four years.  

Let's get some KISS *SP out soon, and see what happens.  Maybe
"experimental" is good enough for now.  There are issues where I
am far from sure that they'll work.  But the lack of *SP scopes
isn't one of them.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Feb 2008 10:17:13 -0800

On Feb 22, 2008, at 5:00 AM, Charles Lindsey wrote:

>> When messages enter into infrastructure supporting messages  
>> normally carried by SMTP, then the policy defined for SMTP should  
>> be used.  This may block messages from other transports integrated  
>> into SMTP related infrastructure.  When NTTP messages never touch  
>> SMTP infrastructure, and the policy scope is s=SMTP, then NTTP  
>> messages are excluded from assertions of being signed.  This  
>> default would create less astonishment, and not affect NTTP  
>> messages that are handled separately from those related to SMTP.
>
> I can think of nothing more astonishing to the readers of some  
> newsgroup and of its associated mailing lists that to have some  
> messages propagating freely within the newsgroup but not being  
> visible within the mailing list.

Regardless of the scope parameter, SSP policy will potentially create  
a problem for messages introduced into SMTP.  Limitation of such  
abilities is a completely separate issue.  Nevertheless SSP policy  
scope would be able to establish explicit requirements at protocol  
bridges, and within the separate protocol itself, through assertions  
such as:

1) Both NTTP and SMTP are "all" signed
2) SMTP is "all" signed, excluding NTTP from the "all" signed assertion
3) Use of NTTP is disavowed by the domain.
4) Use of SMTP and NTTP are disavowed by the domain.

> The more you try to justify this "s=" tag, the deeper into the pit  
> you dig yourself. It is evident to me that the whole idea is utterly  
> indefensible.

There is nothing wrong with declaring SSP policy as pertaining to  
messages handled by SMTP related protocols and could be defined as  
such.  The "s=" tag could also allow a domain to could forgo NTTP to  
ensure NNTP messages are not passed into SMTP as being from their  
domain, such as "s=SMTP:!* to where all different message protocols  
are disavowed.  Perhaps the most useful declaration would be for  
existing domains containing address records, but that wish to disavow  
use of even SMTP.  "s=!*" would avoid subsequent queries for key  
records referenced from the domain, and prevent the continuation of  
queries into the parent domain.  "s=*!" would be more effective than  
an invalid signature and an "all" or "repudiate-able" assertion.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Feb 2008 11:21:06 -0800

> know it, e.g., GMaNe could educate its users in its FAQ.

When SSP policy applies to other transport protocols independent of  
SMTP, a prefix of "!" for "Not Used", "-" for "Except", and a protocol  
wildcard of "*" for "Any Other Protocol" as in  [! | -]<protocol>  
would allow construction of the transport sources for DKIM messages.   
If policy scope is defined in the future, a default of "s=SMTP" would  
be required.

> In addition to the domain owners intending to introduce some kind of  
> strict/reject/discard/whatever *SP, they first have to educate their  
> users.  And maybe folks like you have to do something with their  
> mail2news solutions if they want SSP protection.

Agreed.  However, the "s=SMTP" (default) would indicate the domain  
does not sign NNTP messages.  A domain that does sign NNTP to avoid  
mail2news problems, could indicate this by asserting "s=SMTP:NNTP".

> "pgpverify" for its purposes, a document explaining NNTP-DKIM can  
> say what NNTP-*SP is supposed to be, if anything at all.

Using separate policy records would be an option, however, this would  
impose greater overhead.  By stating that today's DKIM policy records  
pertain to governing SMTP related infrastructure, this would clarify  
the scope of this record at least.

> "experimental" is good enough for now.  There are issues where I am  
> far from sure that they'll work.  But the lack of *SP scopes isn't  
> one of them.

Agreed, but a concern still remains with respect to truncating the  
discovery processes.  This becomes especially important as perhaps  
dozens of message protocols attempt to introduce their policies in the  
same fashion.  As more organizations attempt to unite this protocol  
babble, curbing undesired key/policy discovery transactions walking up  
domains not supporting the protocol is likely to only grow in  
importance.

Despite the lack of adoption of various modifiers used by SPF,  
providing a foundation for policy scope within the DKIM policy  
records, with a default of "s=SMTP" would provide a framework for  
future adoption.  Macro expansion features and Exist mechanisms of  
SPF, due to inherent dangers, where strongly argued against.  Removing  
these seldom unused features today from SPF parsing routines would  
help keep the Internet a much safer place.  However, not having a  
general means to truncate policy discoveries related to security  
enhancements of various communication schemes will be placing DNS at  
greater risk again.

To that end, declare the scope of the DKIM policy record is limited to  
SMTP infrastructure, and that publishing DKIM policy necessitate a  
"proof" of protocol use.  In the case of SMTP, this could be  
publishing the "MX" record.  Required "proof" of use protects domains  
that do not support SMTP from being inundated with a flurry of  
undesired transactions that only result in an "uncertain" status for  
the abusive message inducing undesired traffic.  Disavowing use of a  
protocol refutes abusive messages to a greater degree than attempting  
to validate message signatures and applying the "all" or "repudiate- 
able" policy assertions.

-Doug