Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM

Elizabeth Zwicky <zwicky@yahoo-inc.com> Tue, 02 April 2013 17:54 UTC

Return-Path: <zwicky@yahoo-inc.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101C21F8CD8 for <dmarc@ietfa.amsl.com>; Tue, 2 Apr 2013 10:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.598
X-Spam-Level:
X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cacFgNCpxrEK for <dmarc@ietfa.amsl.com>; Tue, 2 Apr 2013 10:54:19 -0700 (PDT)
Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id A197A21F8CC9 for <dmarc@ietf.org>; Tue, 2 Apr 2013 10:54:17 -0700 (PDT)
Received: from SP1-EX07CAS04.ds.corp.yahoo.com (sp1-ex07cas04.corp.sp1.yahoo.com [216.252.116.155]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r32HrjBZ053174 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 2 Apr 2013 10:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1364925227; bh=2CjtkS47F0wMwhdQqBy6ZvlIiwJJ+dvbD8Bd3K7I5Uk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rtk32TEePjeT9/q974IxMeuOpWb/bSD1pDE/SiHbpqzcGou+YkEzO8MiREJ3/Fck9 NscA+09AVhF3xSwjPVxHjocThLWTK1NEaIXBiDae45UEvrmhqVkNRWXacxfBfjSe+5 T0r35HC3rMgjOzR5wnHuV7hsABSd3msxIB+j27/c=
Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.136]) by SP1-EX07CAS04.ds.corp.yahoo.com ([216.252.116.158]) with mapi; Tue, 2 Apr 2013 10:53:45 -0700
From: Elizabeth Zwicky <zwicky@yahoo-inc.com>
To: "J. Gomez" <jgomez@seryrich.com>
Date: Tue, 02 Apr 2013 10:53:44 -0700
Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM
Thread-Index: Ac4vywTNn3Gu9GGiScm9jwnNORa1tw==
Message-ID: <BA8512F9-5CA9-4F8F-A639-A022DFD522A3@yahoo-inc.com>
References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local>
In-Reply-To: <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 925226007
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 02 Apr 2013 17:54:26 -0000

On Apr 1, 2013, at 4:15 PM, J. Gomez wrote:

> -- makes DMARC more resilient in case any of its underliying authentications mechanisms becomes compromised/broken/moot in the future.

It's not clear to me that this is usefully true.

Let us pretend that DKIM is broken -- you can forge a DKIM signature for anybody you like.

Anybody who needed a DMARC 'both' option before is now out of luck -- DMARC can always pass, so they are vulnerable to whatever problem they would have been vulnerable to without it.

Anybody who actually needed the current DMARC 'any' option is also out of luck, because they can't go to 'both'. 

Only the tiny minority of people who can use 'both' but don't actually need to remain protected, and the net result is that the standard is unusable. There is some benefit, but it is not enough to be worth any significant cost, and adding a new option is a big implementation cost.

	Elizabeth