Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders
>And yet, treating any random third party signature as if it's just as >valid as a first party signature is, as I expect you'd agree, the kind >of security issue that would cause someone to stand up on a chair and >shout "DKIM will never be useful for anything, and you people all suck >toads!" I suppose, although it mostly makes me wonder if there's any way to explain DKIM to the bufophagists. A third party signature from a stranger is useless, I don't ever recall anyone claiming otherwise, and I've never understood why this red herring comes up over and over and over and over and over again. But a first party signature from a stranger is equally useless, unless one finds assertions along the lines of "I, Mr. X, really sent this spam!" to be helpful. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders
John Levine wrote: A third party signature from a stranger is useless, I don't ever recall anyone claiming otherwise, and I've never understood why this red herring comes up over and over and over and over and over again. Let me take a guess. Could it be because you have selective bias to ignore and neglect all security concerns expressed over and over again by legitimizing the existence of unexpected states that is fundamentally conflictive with existing long held private email practices? In layman terms, while stating a 3PS is useless without some form of non-repudiated prior arrangement is plausible, the mere fact for the unexpected existence of 3PS has a tremendous value in the area of mail tampering and fraud detection and protection. IMO, to ignore this is irresponsible. Just consider that by believing a 3rd party signature is useless, this premise alone may be enough to provide justification for a verifier to "discard" any message with a 3rd party signature. Why? Because your model implies there should never exist a 3rd party signature due to its useless value, therefore no legitimate DKIM signer would ever attempt to sign as a 3rd party. Unless your ASP model has specific semantics to not DISCARD 3rd party signatures, as did SSP-01, be careful for what you ask for because this might be exactly what will happen inevitable. After all, you said 3rd party signatures are useless. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders
John Levine wrote: > Trying to forbid random other third party signatures is, as I expect > you'd agree, just silly. And yet, treating any random third party signature as if it's just as valid as a first party signature is, as I expect you'd agree, the kind of security issue that would cause someone to stand up on a chair and shout "DKIM will never be useful for anything, and you people all suck toads!" Yet another reason to leave 3rd party signatures (and toad-sucking) out of scope, I suppose. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders
Hector ranted: > So why do you advocate an inherent "policy and mandate" > against allowing a domain owners (and the key words is > owners) the option and flexibility to opt out with a global > declaration - > >"I don't expect 3rd party signatures in my direct 1 to 1 > private email communications with my target recipients." We get that exact statement from the "discardable" flag. What ASP (and SSP-02) /don't/ permit is for a domain owner to say "I'm cool with 3rd party signatures," either by prior agreement or random happenstance. That's what I want to leave out of scope, and deal with in the future. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1519: SSP-02:Author Signature scope too narrow
On Feb 13, 2008, at 4:50 PM, Jim Fenton wrote: Douglas Otis wrote: Jim, Almost. Here is the 10,000 foot view from the two perspectives. View 1: (recommended) The verifier does not police how someone might make use of a DKIM key. Restrictions on the key (g= t= parameters) only limit which identities can be associated with a signature. Policy, on the other hand, is constrained only by DNS hierarchy. When a domain signs a message for a group of users within different sub-domains, the message would be considered compliant with an "all" assertion when a valid signature's d= parameter is at or above the From email- address domain (referencing the policy). The identity and header associated with a signature is not germane to DKIM policy. This seems like the rarest of situations: Not only do you have multiple From addresses in the message, which is rare to start with, but you're considering a case where the multiple From addresses come from different subdomains and optimizing for that case so that only one signature will work for any of them. There is some confusion. This is _not_ about multiple From headers. A message can be signed where there are multiple email-addresses within different headers that are also within the same domain. This situation is not rare at all. This seems like it's trying to redefine RFC 4871, where the default value of i= comes from the value of d=, and if a domain wants to sign for a subdomain it MUST include an i= tag with the name of the subdomain. When the key has not been restricted from being able to sign for the sub-domain, why would it matter what had been used in the i= parameter. By the same token, the i= could be blank and the default would become the d= parameter. Although this signature might not directly associate with the identity within the From header, it would still provide a valid signature. Unless restricted by the key, there is no reason to assume the signature is any less trustworthy as a result. The From identity is included within the signature's hash after all. If a signature was supposed to be valid for any subdomain, RFC 4871 should say that. A signature can be valid without being associated with any specific identity. Don't confuse being valid with being associating with a specific identity. These are too entirely separate issues. So: -1 View 2: (conservative) The verifier should police how someone might make use of a DKIM restricted key. Restrictions on the key (g= t= parameters) limit which identities can be associated with a signature. In essence, the sub-domain and identity within the From email-address must be encompassed within the scope of the key's restrictions. In the case of restricted keys, the key should be able to have provided a valid signature for the From email-address identity and domain (referencing the policy). The identity and sub-domain associated with a signature is not germane to DKIM policy. The signature might be on-behalf-of of some other identity within headers other than the From, or even in no header at all. Ignoring the subdomain stuff (see above) I think this corresponds to what I said, although you're using the term "identity" where I'm using "local-part". Identity may also include sub-domains and local-parts extending the range of the domain's signature. But what you want to do is check the key restriction against an Author Address, not the i= value, right? First and foremost, the signature must be valid. When a key is g= restricted, the i= parameter must conform to the g= restriction. For the conservative view, this would be saying that restricted keys must be signing on behalf of the From header identity. However, there are two separate key restrictions that come into play. Each of these restrictions should be handled separately. The t= parameter may not relate directly to the i= parameter. In other words, local-parts may vary when the key is only restricted by the t=s parameter. -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 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
Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto reduce DNS overhead for SSP Discovery and to detectfraudulent messages
Arvel Hathcock wrote: > I'll add a -1 to mandating publishing of MX as well. > > Do we have enough votes to put this to bed and move on? In case we don't, here's one more. -1 And in case that doesn't count, I raise your -1 to my -1, which means -2 or I agree or no mandate. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ 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] ISSUE 1519: SSP-02:Author Signature scope too narrow
Douglas Otis wrote: On Feb 13, 2008, at 3:46 PM, Jim Fenton wrote: Douglas Otis wrote: See: https://rt.psg.com/Ticket/Display.html?id=1519 Also relates to issue 1399 "clarify i= vs. SSP" if I understand that correctly. To briefly summarize, I understand Doug's issue to be the question of whether the local-part of an Author Address should be matched against the i= value, if a local-part is present in i=. SSP matches the local part if present draft-levine-asp-00 matches only the domain part Doug is suggesting a third alternative: to match the Author Address against the g= field in the key record used to verify the signature. Doug, please verify that I understand the issue correctly before I invest a lot of keystrokes in responding. Jim, Almost. Here is the 10,000 foot view from the two perspectives. View 1: (recommended) The verifier does not police how someone might make use of a DKIM key. Restrictions on the key (g= t= parameters) only limit which identities can be associated with a signature. Policy, on the other hand, is constrained only by DNS hierarchy. When a domain signs a message for a group of users within different sub-domains, the message would be considered compliant with an "all" assertion when a valid signature's d= parameter is at or above the From email-address domain (referencing the policy). The identity and header associated with a signature is not germane to DKIM policy. This seems like the rarest of situations: Not only do you have multiple From addresses in the message, which is rare to start with, but you're considering a case where the multiple From addresses come from different subdomains and optimizing for that case so that only one signature will work for any of them. This seems like it's trying to redefine RFC 4871, where the default value of i= comes from the value of d=, and if a domain wants to sign for a subdomain it MUST include an i= tag with the name of the subdomain. If a signature was supposed to be valid for any subdomain, RFC 4871 should say that. So: -1 View 2: (conservative) The verifier should police how someone might make use of a DKIM restricted key. Restrictions on the key (g= t= parameters) limit which identities can be associated with a signature. In essence, the sub-domain and identity within the From email-address must be encompassed within the scope of the key's restrictions. In the case of restricted keys, the key should be able to have provided a valid signature for the From email-address identity and domain (referencing the policy). The identity and sub-domain associated with a signature is not germane to DKIM policy. The signature might be on-behalf-of of some other identity within headers other than the From, or even in no header at all. Ignoring the subdomain stuff (see above) I think this corresponds to what I said, although you're using the term "identity" where I'm using "local-part". But what you want to do is check the key restriction against an Author Address, not the i= value, right? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1519: SSP-02:Author Signature scope too narrow
On Feb 13, 2008, at 3:46 PM, Jim Fenton wrote: Douglas Otis wrote: See: https://rt.psg.com/Ticket/Display.html?id=1519 Also relates to issue 1399 "clarify i= vs. SSP" if I understand that correctly. To briefly summarize, I understand Doug's issue to be the question of whether the local-part of an Author Address should be matched against the i= value, if a local-part is present in i=. SSP matches the local part if present draft-levine-asp-00 matches only the domain part Doug is suggesting a third alternative: to match the Author Address against the g= field in the key record used to verify the signature. Doug, please verify that I understand the issue correctly before I invest a lot of keystrokes in responding. Jim, Almost. Here is the 10,000 foot view from the two perspectives. View 1: (recommended) The verifier does not police how someone might make use of a DKIM key. Restrictions on the key (g= t= parameters) only limit which identities can be associated with a signature. Policy, on the other hand, is constrained only by DNS hierarchy. When a domain signs a message for a group of users within different sub-domains, the message would be considered compliant with an "all" assertion when a valid signature's d= parameter is at or above the From email-address domain (referencing the policy). The identity and header associated with a signature is not germane to DKIM policy. View 2: (conservative) The verifier should police how someone might make use of a DKIM restricted key. Restrictions on the key (g= t= parameters) limit which identities can be associated with a signature. In essence, the sub-domain and identity within the From email-address must be encompassed within the scope of the key's restrictions. In the case of restricted keys, the key should be able to have provided a valid signature for the From email-address identity and domain (referencing the policy). The identity and sub-domain associated with a signature is not germane to DKIM policy. The signature might be on-behalf-of of some other identity within headers other than the From, or even in no header at all. -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
[ietf-dkim] Re: NEW ISSUE: SSP-02: Policy Scope
Douglas Otis 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. > 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. 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 ___ 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] ISSUE 1519: SSP-02:Author Signature scope too narrow
Douglas Otis wrote: See: https://rt.psg.com/Ticket/Display.html?id=1519 Also relates to issue 1399 "clarify i= vs. SSP" if I understand that correctly. To briefly summarize, I understand Doug's issue to be the question of whether the local-part of an Author Address should be matched against the i= value, if a local-part is present in i=. SSP matches the local part if present draft-levine-asp-00 matches only the domain part Doug is suggesting a third alternative: to match the Author Address against the g= field in the key record used to verify the signature. Doug, please verify that I understand the issue correctly before I invest a lot of keystrokes in responding. -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
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
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
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
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
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
> >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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
Douglas Otis wrote: There appears to be confusion regarding the impact of this requirement. A requirement to publish an MX record when also publishing SMTP policy does _not_ impact RFC 2821, which had been the basis for these objections. When the concern is that DKIM Signing policy records apply to other types of message traffic, then _different_ policy records must be published for each of the different protocols or a scope parameter is needed. There should be a general stipulation that the scope of _asp, _ssp, _adsp, or whatever it is called is limited to SMTP. When the policy affects other types of message traffic, such as IM or UUDP, the policy records MUST BE specifically defined for the type of traffic covered by the policy. I'm not confused about the impact of this requirement. But I don't see the benefit of this requirement, not even the efficiency benefit that you claim. I see it as an unnecessary requirement, and I oppose it on that basis. Email policy discovery _will_ impact domains being forged in fraudulent email. These domains may not be either sending or accepting SMTP traffic as well. By establishing a convention that SMTP/DKIM policy is only valid in conjunction with a published MX record does not change how SMTP or any other message handling protocol operates. This requirement only affects the publishing of SMTP related policy. It is rather unlikely there will be only one policy implemented for SMTP, NNTP, UUCP, etc. In addition, policy discovery adds to the DNS burden caused by an undefined number of subsequent key look-ups, existence tests, and tree walking for policy. There may be any number of signatures within different sub-domains contained within a message. The MX record mandate, in the case of SMTP policy, provides a means to truncate subsequent SMTP transactions to both protect the domain and to disavow any related traffic purportedly covered by policy. I see that you have opened a separate issue regarding scope. Good. Let's discuss it there. -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
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
[ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
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
[ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
On Feb 13, 2008, at 10:52 AM, Jim Fenton wrote: Douglas Otis wrote: On Feb 12, 2008, at 7:53 AM, Frank Ellermann wrote: Douglas Otis wrote: the SSP draft should mandate publishing MX records whenever an SSP record is also published. -1 SSP (or ASP) have no business to "mandate" MX records, that's not their job. MX records are not required for (2)821(bis) interoperability, and RFC 2119 has a very clear policy about arbitrary MUSTard. The MUST only occurs in conjunction with publishing SSP records. This does not mandate publishing of MX records when SSP is not used. -1 to this proposal, for the reasons that Wietse and Frank have mentioned. Furthermore, if the domain publishes an SSP record, the SSP lookup algorithm never gets to the step that might benefit from the publication of an MX record. Jim, There appears to be confusion regarding the impact of this requirement. A requirement to publish an MX record when also publishing SMTP policy does _not_ impact RFC 2821, which had been the basis for these objections. When the concern is that DKIM Signing policy records apply to other types of message traffic, then _different_ policy records must be published for each of the different protocols or a scope parameter is needed. There should be a general stipulation that the scope of _asp, _ssp, _adsp, or whatever it is called is limited to SMTP. When the policy affects other types of message traffic, such as IM or UUDP, the policy records MUST BE specifically defined for the type of traffic covered by the policy. Email policy discovery _will_ impact domains being forged in fraudulent email. These domains may not be either sending or accepting SMTP traffic as well. By establishing a convention that SMTP/DKIM policy is only valid in conjunction with a published MX record does not change how SMTP or any other message handling protocol operates. This requirement only affects the publishing of SMTP related policy. It is rather unlikely there will be only one policy implemented for SMTP, NNTP, UUCP, etc. In addition, policy discovery adds to the DNS burden caused by an undefined number of subsequent key look-ups, existence tests, and tree walking for policy. There may be any number of signatures within different sub-domains contained within a message. The MX record mandate, in the case of SMTP policy, provides a means to truncate subsequent SMTP transactions to both protect the domain and to disavow any related traffic purportedly covered by policy. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto reduce DNS overhead for SSP Discovery and to detectfraudulent messages
> I'll add a -1 to mandating publishing of MX as well. > > Do we have enough votes to put this to bed and move on? In case we don't, here's one more. -1 -- Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto reduce DNS overhead for SSP Discovery and to detectfraudulent messages
I'll add a -1 to mandating publishing of MX as well. Do we have enough votes to put this to bed and move on? >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Jon Callas >Sent: Wednesday, February 13, 2008 3:17 PM >To: DKIM List >Subject: Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record >publishing mandateto reduce DNS overhead for SSP Discovery and >to detectfraudulent messages > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >I'd like to add a big -1 to mandating publishing MX, >conflating DKIM and SMTP and so on. > > Jon > >-BEGIN PGP SIGNATURE- >Version: PGP Universal 2.6.3 >Charset: US-ASCII > >wj8DBQFHs1BPsTedWZOD3gYRAsftAKC6GbS3EfXP+8j1dKpe2o8uSwGYsACgjEfs >SE8mHyOtaH6SvrUKFbxSkJI= >=irVG >-END PGP SIGNATURE- >___ >NOTE WELL: This list operates according to >http://mipassoc.org/dkim/ietf-list-rules.html > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to add a big -1 to mandating publishing MX, conflating DKIM and SMTP and so on. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHs1BPsTedWZOD3gYRAsftAKC6GbS3EfXP+8j1dKpe2o8uSwGYsACgjEfs SE8mHyOtaH6SvrUKFbxSkJI= =irVG -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
Jim Fenton wrote: The MUST only occurs in conjunction with publishing SSP records. This does not mandate publishing of MX records when SSP is not used. -1 to this proposal, for the reasons that Wietse and Frank have mentioned. Furthermore, if the domain publishes an SSP record, the SSP lookup algorithm never gets to the step that might benefit from the publication of an MX record. +1 to your -1. In other words, I agree with you. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
Douglas Otis wrote: On Feb 12, 2008, at 7:53 AM, Frank Ellermann wrote: Douglas Otis wrote: the SSP draft should mandate publishing MX records whenever an SSP record is also published. -1 SSP (or ASP) have no business to "mandate" MX records, that's not their job. MX records are not required for (2)821(bis) interoperability, and RFC 2119 has a very clear policy about arbitrary MUSTard. The MUST only occurs in conjunction with publishing SSP records. This does not mandate publishing of MX records when SSP is not used. -1 to this proposal, for the reasons that Wietse and Frank have mentioned. Furthermore, if the domain publishes an SSP record, the SSP lookup algorithm never gets to the step that might benefit from the publication of an MX record. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Issue Tracker down
I note that the issue tracker is back, and I see the following recently-added issues: 1546: Discardable inappropriately specifies possible verifier action (Otis) 1547: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages (Otis) 1548: Policies Required to close security threats (Santos) 1549: Security Threats are [not] well defined (Santos) 1550: Rename SSP to ASP (Crocker) Thanks, Eliot! -Jim Eliot Lear wrote: please be advised that the issue tracker is currently down. I don't yet have an ETR. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders
John Levine wrote: That's not quite what we had in mind. As I see it, 3rd party signing is only acceptable when the domain owner wants to permit it -- It would be possible to design a system in which domain A says that it endorses domain B's signature on mail with an author address at A, but if you dig through the list archives, you'll find that we rejected that expansion of SSP quite a while ago. Indeed, it was issue tracked, consensus called and documented in RFC5016. This is a very dead horse. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE: SSP-02: MX Record publishing mandate to reduceDNS overhead for SSP Discovery and to detect fraudulent messages
On Tue, 12 Feb 2008 18:57:32 -, Douglas Otis <[EMAIL PROTECTED]> wrote: On Feb 12, 2008, at 7:53 AM, Frank Ellermann wrote: Douglas Otis wrote: the SSP draft should mandate publishing MX records whenever an SSP record is also published. -1 SSP (or ASP) have no business to "mandate" MX records, that's not their job. MX records are not required for (2)821(bis) interoperability, and RFC 2119 has a very clear policy about arbitrary MUSTard. The MUST only occurs in conjunction with publishing SSP records. This does not mandate publishing of MX records when SSP is not used. Exactly. An SSP record is published using the DNS system. One of the functions of the SSP draft is to specify the precise means of such publication. So there is no reason why it should not say "An SSP record MUST NOT be published unless there also exists a corresponfing MX record". So if someone publishes one contary to that, then it is not a valid SSP record, and hence may be ignored by evaluators. I son't see any problem with doing that, provided of course that the technical benefits warrant it. -- 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: Security Threat: Unexpected Third PartySenders
John Levine wrote: That's not quite what we had in mind. As I see it, 3rd party signing is only acceptable when the domain owner wants to permit it -- It would be possible to design a system in which domain A says that it endorses domain B's signature on mail with an author address at A, but if you dig through the list archives, you'll find that we rejected that expansion of SSP quite a while ago. hm, I don't believe that is true John. I think you are reading your own adaptation where stripping down SSP-01, removing such Verifier Accepable 3rd party Signature semantics from the spec, relabeling it ASP does not make it "while ago". I think I am fairly certain ASP is only week or so old. Anyway, while there were various proposals and ideas not everyone was tickled pink with, it was quite clear the concept was feasible enough to get written in stone in SSP-01: 2.11. Verifier Acceptable Third-Party Signature A Verifier Acceptable Third-Party Signature is a Third-Party Signature that the Verifier is willing to accept as meaningful for the message under consideration. The Verifier may use any criteria it deems appropriate for making this determination. 3. Operation Overview .. 2. All messages from this domain are signed. Messages containing a Verifier Acceptable Third-Party Signature MUST NOT be considered Suspicious. NON-NORMATIVE RATIONALE: Third-party signatures, since they can potentially represent any domain, are considered more likely to be abused by attackers seeking to spoof a specific address. It may therefore be desirable for verifiers to apply other criteria outside the scope of this specification in deciding to accept a given third-party signature. For example, a list of known mailing list domains used by addresses served by the verifier might be specifically considered acceptable third-party signers. And in RFC 5016, it goes as far as using suggesting DNS CNAME techniques: 6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may set an NS record for _domainkey.example.com to delegate to an email provider who manages the entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. Given the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: Rename SSP to ASP
J D Falk wrote: Since they're so similar, I'd think that changing the name as part of a continued consensus-based[1] merger process might help to reduce that confusion. -1. I don't want to comparison / contrast a potentially moving target. It seems easier at this point just to open issues on -SSP-02. Otherwise we're going to take forever to get this work done. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADMIN: Mipassoc. org mailing list host change -- 2/16-17
Folks, Sometime this coming weekend, 2/16-17, mipassoc.org will be re-hosted to to a new machine. During the few hours of the transition, list activity will be suspended. This should not be visible, other than delaying distribution of new postings. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
