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
