Re: [ietf-dkim] Re: NEW ISSUE: SSP-02: Policy Scope
On Feb 14, 2008, at 4:01 PM, Frank Ellermann wrote: Douglas Otis wrote: SMTP RFC2821 NNTP RFC3977 MSRP RFC4975 UUCP RFC976 Did you understand what I meant when I mentioned gateways ? While this may not be a good initial list for transport protocols, this was to illustrate more than one "public" transport is affected. It would be incorrect to assume that a DKIM policy assertion applies to all such transports. A receiver may not aggregate messages from all transports into mailboxes primarily served by SMTP. Regardless of the transport, DKIM might be used nonetheless. When a transmitting domain has not implemented DKIM for a specific transport protocol, then an assertion that "all" messages have been signed needs to reflect where this has been implemented. Receivers will need to decide whether they wish to merge the messages from one transport into a mailbox served by SMTP. When the transport has been modified by an up stream third-party, then receivers down stream are likely to apply the policy pertinent to current transport. The syntax of the policy record affords enough flexibility for the transmitter to express how they wish to see policy applied. 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. For a verifier at an MTA it is irrelevant how the message might have started, if it arrives as "mail" (likely SMTP) it is "mail", and a From header field is a From header field without studying the fine print in RFC 4356, RFC.usefor-usefor, RFC 976, etc. RFC 976 has status "unknown", this means MAJOR TROUBLE. I just read John's appeal against the first RFC 4356 attempt again, it was a disaster... Thanks for the input. It would seem this should be moved to an IANA controlled protocol list. policy-s-tag = %x73 [FWS] "=" [FWS][exclude|disavow] policy-s-tag-type No more [FWS] in SSP-02. it's now *WSP. It's now clear that net- utf8 sticks to "disavow" HT, maybe SSP-03 should say *SP. Sorry about that, was doing a quick cut and paste from the RFC 4871. Take #3. s= Policy Scope (plain-text; OPTIONAL; default is "*"). A colon- separated list of policy scopes specify which protocols to which this policy record applies. Verifiers for a given protocol MUST ignore this record when the appropriate protocol has not been listed. Currently defined protocol types are as follows: * matches against all unlisted transport protocols ! disavows protocol use - excludes protocol from policy assertions SMTP RFC2821 NNTP RFC3977 See IANA SSP Policy List for additional protocols. This tag is able to tailor the application of policy against various transport protocols which may now or in the future implement DKIM. This tag can also disavow use of specific protocols to repudiate references to the domain. A gateway that converts protocols ahead of the receiver may change the policy applied. When uniform policy is desired for all possible transports no tag is necessary, as the default is "s=*". When a receiver combines messages from various transports, it is RECOMMENDED the policy pertaining to the primary transport protocol be applied. In most cases, this policy would be for SMTP. As example, "s=SMTP:-NNTP:!*" would mean this domain only uses SMTP and NNTP to exchange messages, but that this policy does not apply against NNTP. When a protocol has been disavowed, any further DKIM related transactions should cease. ABNF: policy-s-tag = %x73 [WSP] "=" [WSP][exclude|disavow] policy-s-tag- type 0*( [WSP] ":" [WSP] policy-s-tag-type ) disavow = "!" exclude = "-" policy-s-tag-type = "SMTP" / "NNTP" / "*" / x-policy-s-tag-type x-policy-s-tag-type = hyphenated-word ; for future extension -Doug ___ 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: > SMTP RFC2821 > NNTP RFC3977 > MSRP RFC4975 > UUCP RFC976 Did you understand what I meant when I mentioned gateways ? > 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. For a verifier at an MTA it is irrelevant how the message might have started, if it arrives as "mail" (likely SMTP) it is "mail", and a From header field is a From header field without studying the fine print in RFC 4356, RFC.usefor-usefor, RFC 976, etc. RFC 976 has status "unknown", this means MAJOR TROUBLE. I just read John's appeal against the first RFC 4356 attempt again, it was a disaster... > policy-s-tag = > %x73 [FWS] "=" [FWS][exclude|disavow] policy-s-tag-type No more [FWS] in SSP-02. it's now *WSP. It's now clear that net-utf8 sticks to "disavow" HT, maybe SSP-03 should say *SP. 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
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
On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote: On Wed, 13 Feb 2008 22:46:10 -, Douglas Otis <[EMAIL PROTECTED] abuse.org> 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: * 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected ThirdPartySenders
Siegel, Ellen wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:ietf-dkim- [EMAIL PROTECTED] On Behalf Of J D Falk Explicitly out of scope. Because not all 3rd party signatures on email are "random", and there are a number of valid use cases that include them. hm, this sounds like an explicit in scope statement. So essentially, if I read you correctly, you want MTAs to completely ignore messages with 3rd party signatures as if the message was never signed? At what point or stage during the transport and/or delivery process do they become "in play" and for whom? According to Falk, if I read him right, he indicated a domain can use DKIM=DISCARDABLE to protect against unwanted 3rd party signatures. Do you agree? -- 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 ThirdPartySenders
Wietse Venema wrote: John Levine wrote: Trying to forbid random other third party signatures is, as I expect you'd agree, just silly. J D Falk: 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. Siegel, Ellen: Explicitly out of scope. Because not all 3rd party signatures on email are "random", and there are a number of valid use cases that include them. +1. This horse is dead and stays dead. I like a quote that I think I once heard attributed to Usenet: "a stain in the middle of the road where once laid a dead horse" Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected ThirdPartySenders
John Levine wrote: > Trying to forbid random other third party signatures is, as I expect > you'd agree, just silly. J D Falk: > 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. Siegel, Ellen: > Explicitly out of scope. Because not all 3rd party signatures on email > are "random", and there are a number of valid use cases that include > them. +1. This horse is dead and stays dead. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected ThirdPartySenders
> -Original Message- > From: [EMAIL PROTECTED] [mailto:ietf-dkim- > [EMAIL PROTECTED] On Behalf Of J D Falk > > 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. Explicitly out of scope. Because not all 3rd party signatures on email are "random", and there are a number of valid use cases that include them. Ellen ___ 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 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] 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 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: Issue Tracker down Re: [ietf-dkim] ISSUE: Rename SSP to ASP
Eliot Lear wrote: please be advised that the issue tracker is currently down. I don't yet have an ETR. The issue tracker is indeed back up. I, however, will be offline until Saturday. Expect more issues to be opened then. Thanks to Randy Bush for prompt response and assistance. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
