[dmarc-ietf] Simple authorization offers reasonable control over messaging resources
Douglas Otis <doug.mtview@gmail.com> Thu, 14 May 2015 23:06 UTC
Return-Path: <doug.mtview@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3601A9140 for <dmarc@ietfa.amsl.com>; Thu, 14 May 2015 16:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr2kAX6Qkasu for <dmarc@ietfa.amsl.com>; Thu, 14 May 2015 16:06:53 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4583F1A1A32 for <dmarc@ietf.org>; Thu, 14 May 2015 16:06:53 -0700 (PDT)
Received: by pdbqb6 with SMTP id qb6so2148107pdb.0 for <dmarc@ietf.org>; Thu, 14 May 2015 16:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OlJVyehiWJDwUzwisNhitFMLnaSaejJR0pPk3mgcBuI=; b=MivoEwFvZZYx30bfIdmU519GUwM/Uf6DvTUVHxBVp1xZ+1EkPpN7E2l1WRmobU2dfy tnilFw3H4fL4H1tyEIaRsAzaWZO6ja+1L2OaW9EuGYpw+t1uLgul6Dd24m6FuOWjh2sM x+vVI3vMkKssHyHeNcpK+GXR+75eGntjLqE4QstIl1p06gngeFSsjAtE+X319KqDXSgd QQdp3GEKMRPprY/ulu0k2N/Uuif+Euc6P8EGcCeJVEog5CMja/4r1HJjcFanpYCbd9rj je/Y7peCXFkUFuvNIT8dZpyeDuUAlRYoIGQEAy0mxWNTcx+DUNqPzNA0Q/keBIAeh1/f ZKSQ==
X-Received: by 10.66.221.193 with SMTP id qg1mr12182136pac.134.1431644785799; Thu, 14 May 2015 16:06:25 -0700 (PDT)
Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id eo3sm225194pbd.66.2015.05.14.16.06.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 16:06:24 -0700 (PDT)
Message-ID: <55552A6C.5060101@gmail.com>
Date: Thu, 14 May 2015 16:06:20 -0700
From: Douglas Otis <doug.mtview@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dmarc@ietf.org
References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <CAL0qLwYeWuovoCnK-Fo9PMajmAgRsxjpXav=ZuDL2A7jm2YLuw@mail.gmail.com> <14447.1431266709@vindemiatrix.encs.concordia.ca> <CAL0qLwbE_30cYWyRXCXkFbw4EMjwX-cy=48+o+c4qyrJY4LeLA@mail.gmail.com> <CAL0qLwbH6qTWhWVjpFAKmYU_fTdx8Hyy1PrE0ztLvG=3xmP_TA@mail.gmail.com> <554FEBB4.5050805@gmail.com> <CAL0qLwaVJY8eecoXV_Ctsxu5D5k+K6sg0dsQZtxafA22s4N1Vg@mail.gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <CAL0qLwZwnopXBvC5XUMV1tkw43eDrf1PJu0EduND_-v_ku8dFw@mail.gmail.com> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <CAL0qLwbBeQw3AgOM+MVmQyQoJNc15-vX2vBY9n2JheDgVJxFwQ@mail.gmail.com>
In-Reply-To: <CAL0qLwbBeQw3AgOM+MVmQyQoJNc15-vX2vBY9n2JheDgVJxFwQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/lCJ0Wos4nmDIvkXtUuHIPBo09fM>
Subject: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 23:06:56 -0000
On 5/14/15 4:54 AM, Murray S. Kucherawy wrote: > On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull <stephen@xemacs.org> > wrote: > >> > What gets added from here forward really needs to be as innocuous >> > as possible. I believe we're in a position where things like SPF >> > and DKIM are still young enough that their implementations are >> > malleable, >> >> I'm not sure what you mean. Now that I actually know what those >> protocols do (and DMARC itself, for that matter), I don't really see >> how they can be much improved. Do you mean the policy engines that >> make decisions based on the output of SPF and DKIM implementations? >> > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more > likely to succeed than anything along the lines of "Everyone start using > and paying attention to Sender", "Let's register yet another Sender-type > field", or "Registration scheme X". The operational changes required for > those three families of solutions are too enormous and involve too many > wildcards for me to believe they stand a chance of success. Dear Murray, The Sender header field when present has been defined for decades to represent the sending agent! DMARC improved delivery registration accuracy for TRANSACTIONAL messages based on the SMTP MailFrom parameter (bounce address) or DKIM (unrelated to any field) where either is allowed to fail. For TRANSACTIONAL email, combining these two marginal authorization schemes easily adjusted to relate with the From header field offered a low percentage authorization failure to better ensure compliance with a restrictive policy. The expediency this allowed did not justify disrupting valid and legitimate exchanges not limited to transactional or direct messaging configurations. Neither DKIM nor SPF authenticate an actual message source, but simple authorization offers reasonable control over messaging resources. DMARC is fine when messages are limited to direct exchange, but fail badly when exchanges make use of the Sender header field that may signify use of mediators or other resources. At one time DMARC even recommended against issuing non-transactional messages, but acknowledgement of DMARC's potential disruption of normal email interchange was dropped. Commercially available products for years have been able to clearly indicate the entity trusted at providing a message. It seems DMARC assumes recipients are too easily misled and can't be trusted to deal with S/MIME, OpenPGP, or MUAs that verify and display the Sender header field and think everyone is better able to deal with munged From header fields. The TPA-Label is able to thwart wildcards simply by publishing a negative wildcarded label. A practice that won't work with DNS-SD. A sender must have reasonable control over the resources they authorize. Any double signing scheme relaying authorization to a third-party via DKIM can not control the authorized resources since the entire message body may change and DKIM can be replayed to any destination by design. Without adequate control, authorization protections fail simply because neither SPF or DKIM are able to authenticate the source, nor can DKIM offer an expedient authorization retraction in say a 5 to 15 minute range. While I commend efforts made at fleshing out your version of the ATPS protocol, due to the inherent hurdles introduced for third-parties it was unlikely this scheme would be adopted. The lesson is DKIM offers a poor method to signal changes beyond those already expected. There was no reason to change how a third-party is verified since they too can use DKIM and SPF or even DANE or the HELO parameter for that matter. The correct place to signal such change is at the DMARC assertion. See Third-Party Authorization example of: "sam=tpa; and tpa=third-party-authority.example.com;" https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 This scheme involves a simple DNS server operating an isolated zone separated from other domain services and can even be published by a different domain. This approach allows the _tpa zone to be maintained as a community effort or as a specialty service to ensure the sender has reasonable and nearly immediate control over the resources they authorize. By being able to include policy for the Sender header field, DMARC can become compatible with RFC5322. While some might describe this a complex authorization scheme, it can be combined with <https://tools.ietf.org/html/draft-levine-dkim-conditional-01> draft-levine-dkim-conditional to offer a resource record where only the base portion of the domain might be included to guard against domain hash collisions. TPA-Label that had the goal of reducing collateral damage caused by compromised accounts or resources, can be combined with draft-levine-dkim-conditional to signal when this limited signature should be included and which domain needs to be authorized. Because this uses very simple resource records, is should scale far better than SPF and yet permit a means to establish an informal federation scheme to better protect email infrastructure with low latency abuse responses. TPA-Label does not make handling third-party messages harder. Instead, TPA-Label offers a simple way to signal which domains require exceptional handling. Without such a feature, DMARC can not be seen as being compatible with RFC5322. Again, we will happily help any large ESP configure and maintain their services to make use of this scheme and even offer the needed resources. Regards, Douglas Otis
- [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Anne Bennett
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Terry Zink
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Anne Bennett
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Terry Zink
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Anne Bennett
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] double signing and what DMARC ac… John Levine
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] double signing and what DMARC ac… Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] double signing and what DMARC ac… John Levine
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] double signing and what DMARC ac… Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] double signing and what DMARC ac… John R Levine
- Re: [dmarc-ietf] double signing and what DMARC ac… Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Scott Kitterman
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Murray S. Kucherawy
- [dmarc-ietf] Simple authorization offers reasonab… Douglas Otis
- Re: [dmarc-ietf] Simple authorization offers reas… Terry Zink
- Re: [dmarc-ietf] Simple authorization offers reas… Murray S. Kucherawy
- Re: [dmarc-ietf] Simple authorization offers reas… Hector Santos
- Re: [dmarc-ietf] Simple authorization offers reas… MH Michael Hammer (5304)
- [dmarc-ietf] Sender: vs. From: (was Re: Simple au… Dave Crocker
- Re: [dmarc-ietf] Simple authorization offers reas… Hector Santos
- Re: [dmarc-ietf] Simple authorization offers reas… Hector Santos
- Re: [dmarc-ietf] Simple authorization offers reas… MH Michael Hammer (5304)
- Re: [dmarc-ietf] Sender: vs. From: (was Re: Simpl… Murray S. Kucherawy
- Re: [dmarc-ietf] Sender: vs. From: (was Re: Simpl… Dave Crocker
- Re: [dmarc-ietf] Sender: vs. From: (was Re: Simpl… Hector Santos
- Re: [dmarc-ietf] Sender: vs. From: (was Re: Simpl… Douglas Otis
- Re: [dmarc-ietf] DMARC ATPS Interop Note Franck Martin
- Re: [dmarc-ietf] DMARC ATPS Interop Note John Levine
- Re: [dmarc-ietf] DMARC ATPS Interop Note Franck Martin
- Re: [dmarc-ietf] DMARC ATPS Interop Note John R Levine
- Re: [dmarc-ietf] DMARC ATPS Interop Note Franck Martin
- Re: [dmarc-ietf] DMARC ATPS Interop Note John R Levine
- Re: [dmarc-ietf] DMARC ATPS Interop Note Stephen J. Turnbull
- Re: [dmarc-ietf] DMARC ATPS Interop Note Hector Santos