Re: [ietf-dkim] Alternative MAiling List Approach
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, July 29, 2010 8:56 PM To: DKIM List Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote: Should the MLM draft suggest From: replacement and addition of Reply- To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On 7/30/2010 9:26 AM, Murray S. Kucherawy wrote: No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. This purporting to be a technical group, precision in the use of labels is broadly viewed as a Good Thing. If you want to characterize it as ADSP-friendly, that would be precise and possibly accurate. As Steve notes, this has nothing to do with DKIM and therefore must not be labeled DKIM-friendly. 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] Alternative MAiling List Approach
On 7/29/10 9:35 PM, Dave CROCKER wrote: Folks need to take note of the fact that a problem that is created by added functionality which is needed by only specialized scenarios is probably best not fixed by adding more mechanism. Dave, The TPA-Label draft offers an ADSP practice that will not disrupt MLM, or other types of informal third-party services. These practices will not depend upon changes in third-party services. In other words, it does not depend upon other mechanisms. It is limited to ADSP. Changes to ADSP will not impact the few existing domains current, limited, and problematic ADSP practices. For domains that will benefit by a strong ADSP anti-phishing stratagem and also wish to use informal third-party services, the overhead of providing authorization should not be a hardship. It will likely require informing their users of an internal webpage where requests for these service can be authorized. Perhaps the industry might even establish a comprehensive list of these informal third-party services, where any outbound traffic to any of these domains could automatically generate needed authorizations, or offer immediate feedback to users without any problematic message even being sent. Prior to authorization, only a few minor checks are needed, which also could be compiled in the industry list of these services. 1) the email-address of the subscriber is confirmed by a pingback message. 2) the messages from the list can be recognized by way of annotation, list-id header fields, etc. If these two elements are met, using tpa-sig or tpa-path assertions in ADSP practice should offer adequate anti-phishing protection. Authorization can be quickly withdrawn when a problem is reported. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On 7/29/10 6:46 PM, Alessandro Vesely wrote: On 29/Jul/10 14:46, Douglas Otis wrote: The TPA-Label approach does _not_ depend upon changes made by the mailing-list! The TPA-Label limits change to code already handling ADSP records, and of course to domains making ADSP assertions. There is only a small number of domains making actionable ADSP assertions. The TPA-Label would allow Author Domains a means to assert explicit exceptions when processing their restrictive ADSP assertions. I agree that TPA-Label would make it more practical to use policies other than unknown. However, I have the feeling that it is more useful for small domains that want to use external services, than for mailing lists. For a large domain whose users are free to subscribe to any list, I see two major concerns: 1. There is no standard way for the domain to learn when any of its users subscribe to a new list. In practice, users would have to check whether the relevant TPA already exists, and possibly apply for it internally, before subscribing. Disagree. Likely most of the domains being heavily phished are already required to careful monitor outbound traffic. If the industry were to compile a list of informal third-party service domains, along with their recommended TPA-Label assertions, any outbound traffic could quickly confirm whether authorization had been granted, and use the compiled list to automatically generate the authorization, or simply point their _tpa list to such an industry list already being published, or immediately reject the message and inform the user they need to find a different alternative. Any recommendation that suggests a targeted and recognized domain should start using other domains or subdomains to conduct public exchanges simply creates new avenues for phishing and will cause greater recipient confusion. In other words, a very bad practice. 2. Granting a TPA implies a good degree of trust. I don't think /any/ mailing list would obtain a TPA from, say, PayPal; the sites who would could then be trusted by proxy by anyone who takes PayPal's assessments for good... Most mailing lists would be safe for a domain in their position to authorize. Most who subscribe already sort these messages. The TPA-Label can even ensure whether a message came from the authorized list. Any mailing list that confirms subscriptions, and adds typical annotations should be safe to authorize. Of course, things like A-R headers would be better. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Yet another alternative mailing list approach
On 30/Jul/10 10:58, Douglas Otis wrote: On 7/29/10 6:46 PM, Alessandro Vesely wrote: 1. There is no standard way for the domain to learn when any of its users subscribe to a new list. Disagree. I'm happy to hear that. The possibility that a domain becomes aware of all of its users' subscriptions has been aired various times before. I think that is in many people's desiderata, and have even tried to devise a way of collaboratively doing it (fixforwarding.org.) Anyway, let's assume that a domain has somehow managed to maintain a database of all the lists that its users are subscribed to. That domain signs all outbound mail and publishes a non-default ADSP. I propose that, when a message is destined to a list, the author domain signs a few header fields only, not the body, and tags the message with a (signed) list-signature-required sort of advice. Messages to multiple list and non-list recipients have to be split, regularly signing the non-list copy. Another way of achieving the same effect would be to standardize all acceptable message changes, together with a MIME-compliant canonicalization. We've already noted that in some cases (plain text, poster-added subject tags, not signing Content-Type, l=) it may work as-is. For the general case, and for the time being, the advice requiring the added list signature guards against replay attacks: Verifiers must ensure that both signatures are valid, unless they are the domain whose signature is missing. 2. Granting a TPA implies a good degree of trust. Most mailing lists would be safe for a domain in their position to authorize. Except that phishermen.com may set up a mailing list for the sole purpose of getting that auth. W.r.t. TPA, this joint-signature proposal only authorizes messages actually destined to a mailing list. Although the list can change the whole body, it is still constrained by the few signed fields. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
In article b1b5f570-e40f-4015-a43d-4f4a89ff5...@wordtothewise.com you write: On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote: Should the MLM draft suggest From: replacement and addition of Reply-To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. +1 on Steve's -1 Mailing lists work perfectly well with DKIM. All this stuff about trying to peer through them and removely validate contributors is something that lists have never done before and we have no reason to invent now. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On Jul 30, 2010, at 12:26 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, July 29, 2010 8:56 PM To: DKIM List Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote: Should the MLM draft suggest From: replacement and addition of Reply- To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. It may well be an ADSP issue - I've not looked in detail at the proposal - and it may be in scope for this document. (I suspect it's also a bad idea, but that's a separate discussion). It's definitely not a DKIM issue, though, and any labeling of a non-DKIM issue as DKIM-friendly would be misleading. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On Friday, July 30, 2010 11:48:22 am Steve Atkins wrote: On Jul 30, 2010, at 12:26 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, July 29, 2010 8:56 PM To: DKIM List Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote: Should the MLM draft suggest From: replacement and addition of Reply- To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. It may well be an ADSP issue - I've not looked in detail at the proposal - and it may be in scope for this document. (I suspect it's also a bad idea, but that's a separate discussion). It's definitely not a DKIM issue, though, and any labeling of a non-DKIM issue as DKIM-friendly would be misleading. IIRC we used to refer to the DKIM base signing spec and ADSP (and all the names it previously had, most of which I've fortunately forgotten) as both being part of DKIM. It seems a bit odd to me to refer to issues with specs produced by the DKIM working group as non-DKIM. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
Should the MLM draft suggest From: replacement and addition of Reply- To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. It may well be an ADSP issue - I've not looked in detail at the proposal - and it may be in scope for this document. (I suspect it's also a bad idea, but that's a separate discussion). It's definitely not a DKIM issue, though, and any labeling of a non-DKIM issue as DKIM-friendly would be misleading. IIRC we used to refer to the DKIM base signing spec and ADSP (and all the names it previously had, most of which I've fortunately forgotten) as both being part of DKIM. It seems a bit odd to me to refer to issues with specs produced by the DKIM working group as non-DKIM. -1. ADSP is fundamentally broken (not as badly as its predecessors) but DKIM is not. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
