Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope //defaults
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope //defaults
On Feb 22, 2008, at 5:53 AM, Frank Ellermann wrote: 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. 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. 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. 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. 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope // defaults
On Feb 21, 2008, at 4:01 AM, Charles Lindsey wrote: On Wed, 20 Feb 2008 18:30:53 -, Douglas Otis [EMAIL PROTECTED] abuse.org wrote: 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. 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. 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. But if they publish s=SMTP and something leaves their domain via 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 reject/discard/suspect/whatever it. 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
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
On Fri, 15 Feb 2008 19:27:29 -, Douglas Otis [EMAIL PROTECTED] wrote: On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote: On Thu, 14 Feb 2008 19:08:41 -, Douglas Otis [EMAIL PROTECTED] wrote: s= Policy Scope (plain-text; OPTIONAL; default is SMTP). A colon- No! The default must be '*'. The concern regarding defaults was addressed in Take #3. This version 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. * 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 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? 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. 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. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 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
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
On Feb 20, 2008, at 3:41 AM, Charles Lindsey wrote: On Fri, 15 Feb 2008 19:27:29 -, Douglas Otis [EMAIL PROTECTED] abuse.org wrote: On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote: On Thu, 14 Feb 2008 19:08:41 -, Douglas Otis [EMAIL PROTECTED] wrote: s= Policy Scope (plain-text; OPTIONAL; default is SMTP). A colon- No! The default must be '*'. The concern regarding defaults was addressed in Take #3. This version 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. * 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 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? 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. 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. 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 - ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
On Thu, 14 Feb 2008 19:08:41 -, Douglas Otis [EMAIL PROTECTED] wrote: On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote: On Wed, 13 Feb 2008 22:46:10 -, Douglas Otis [EMAIL PROTECTED] wrote: 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. 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 PROTECTED] [NO DKIM signature] 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: No! The default must be '*'. * matches all service types ! disavows protocol use SMTPRFC2821 NNTPRFC3977 MSRPRFC4975 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. 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. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 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
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
The prior syntax did not seem to permit enough flexibility. s= Policy Scope (plain-text; OPTIONAL; default is *). 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 protocol types are as follows: * matches all unlisted service types ! disavows protocol use - excludes from policy SMTP RFC2821 NNTP RFC3977 MSRP RFC4975 UUCP RFC976 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. As example, s=SMTP:-UUCP:!* would mean this domain only uses SMTP and UUCP to exchange messages, but that this policy does not apply to UUCP. ABNF: policy-s-tag = %x73 [FWS] = [FWS][exclude|disavow] policy-s-tag- type 0*( [FWS] : [FWS] policy-s-tag-type ) disavow = ! exclude = - policy-s-tag-type = SMTP / NNTP / MSRP / UUCP / * / x-policy-s-tag-type x-policy-s-tag-type = hyphenated-word ; for future extension ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Douglas Otis: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Wietse Venema: Douglas Otis: 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. 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 for the updated proposal. Cosmetic surgery on a dead horse won't bring it back to life. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Wietse Venema wrote: Douglas Otis: 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. 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. What I'd like to know is how we implement the electric chair for violators of this prohibition. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
On Feb 13, 2008, at 1:32 PM, Wietse Venema wrote: Douglas Otis: 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. 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 YESNO 1 No Policy Defined NO YES 2 SMTP Disavowed (cease further transactions) YESYES 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Michael Thomas wrote: What I'd like to know is how we implement the electric chair for 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
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Wietse Venema wrote: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
On Feb 13, 2008, at 3:33 PM, Jim Fenton wrote: Wietse Venema wrote: 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Douglas Otis wrote: On Feb 13, 2008, at 3:33 PM, Jim Fenton wrote: Wietse Venema wrote: 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. 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. 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. 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
At 15:33 13-02-2008, 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
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. 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
