How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead
Hector Santos <hsantos@isdg.net> Thu, 03 October 2013 20:13 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF49121F9B66 for <ietf@ietfa.amsl.com>; Thu, 3 Oct 2013 13:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.301
X-Spam-Level:
X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 9s0bd5cEVNAL for <ietf@ietfa.amsl.com>; Thu, 3 Oct 2013 13:12:52 -0700 (PDT)
Received: from ntbbs.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B553121E8096 for <ietf@ietf.org>; Thu, 3 Oct 2013 12:55:20 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2557; t=1380830112; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BvraxwME9SThEpMkiUaY+FW+g+4=; b=GarF7FEOAYy9F7ClSEqA 4Of9I8D9d2Lki+38Z2TD6aQvkk69IQAQrMIbX9gWFz+RIR6or2MxM+qQ31ie+FKL RU65H/q4x1tPD/sIwHfqJlobMkpDVlOTs4i8HIuhl2o3CT8JJHhvLu20GE2zxCjV abKJrWZR6Zh/gpPb78WZW88=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Thu, 03 Oct 2013 15:55:12 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2997618011.4443.1336; Thu, 03 Oct 2013 15:55:11 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2557; t=1380829723; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5ReIjRo 23CaVFzLFr/RSjDwWGGJbiaZu8JyehWnMwoI=; b=ryi469Xdzz2LBlZSw2dRsvz PAkQUSBCOfn9/t7eZJP421O1YPlwO2xRWd0qfkjWUvszYU+fzg9D27jMiq99hohB 1xjlGWFDvbrEdw3z/8k/BPe6cAqGFr5UlM5pnFoV1izoDyj6qc5d6bb3P7+iSoph xkWavjUEg7GKvYTvDwwI=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Thu, 03 Oct 2013 15:48:43 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2444004878.9.2624; Thu, 03 Oct 2013 15:48:43 -0400
Message-ID: <524DCBA0.1090302@isdg.net>
Date: Thu, 03 Oct 2013 15:55:12 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Douglas Otis <doug.mtview@gmail.com>
Subject: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead
References: <20131002144143.20697.85830.idtracker@ietfa.amsl.com> <CAL0qLwZQcXm=EauyKXVqGaUB99sTQgxf2csy0_N489TdfwRr4A@mail.gmail.com> <524D5ACF.3020008@isdg.net> <2F9821D3-C782-46FD-8AD6-B988CF0E6C55@gmail.com>
In-Reply-To: <2F9821D3-C782-46FD-8AD6-B988CF0E6C55@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba <barryleiba@computer.org>, ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 20:13:03 -0000
On 10/3/2013 1:51 PM, Douglas Otis wrote: > > Dear Hector, > > Indeed, more should be said about underlying reasons. The reason for abandoning ADSP is for the same reason few providers reject messages not authorized by SPF records ending in "-all" (FAIL). Mailing-List software existed long before either of these strategies and domains using mailing lists need to be excluded from having DMARC policies (until a revised ATPS specification able to use normal signatures is published.) The reason for moving toward DMARC is, although aligned policy is only suitable for domains limited to messages of a transactional nature, places where one authorization scheme fails can be mostly recovered by the other which greatly increases the chances of a domain's policy being applied in the desired fashion. > Whether its ADSP, DMARC or anything else, any DKIM resigner has to be aware of the consequences of blind signing. It can not operate in a vacuum as if all of the following documents did not exist: RFC4686 Analysis of Threats Motivating DKIM RFC5016 Requirements for a DKIM Signing Practices Protocol RFC5585 DKIM Service Overview RFC5617 DKIM Author Domain Signing Practices (ADSP) RFC5863 DKIM Development, Deployment, and Operations RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists All of them describe a basic integrated concept of protecting the domain signature which is still a problem to be resolved today otherwise the payoff of the new DKIM "Internet Standard" is still Zilch, Nada, Nil. So if the movement is now towards DMARC, are mailing list software going to support the policies exposed by DMARC restrictive domains? We are not resolving the basic debate that was always with us. Stripping Policy from DKIM framework as a separate SSP, then further relaxing it and changing it to ADSP and now DMARC does not resolve the basic fundamental problem with securing DKIM signatures if middleware are not going to support the concept and continue with blind resigning. Make ADSP historic and DKIM itself is at risk of finally falling into that wasted protocol project as well. Sure everyone is signing but also stripping and replacing everyone's signature, its value has been totally lost. Go figure. I think the requester of this change ought to write a report explaining how making ADSP historic and adopting DMARC minimizes any impact and also helps keep DKIM as a viable mail signature concept to have. How the payoff is finally realized with DMARC rather an ADSP. -- HLS
- Re: Last Call: Change the status of ADSP (RFC 561… John Levine
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- RE: Last Call: Change the status of ADSP (RFC 561… ietfdbh
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Alessandro Vesely
- Re: Last Call: Change the status of ADSP (RFC 561… Scott Kitterman
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- How to protect DKIM signatures: Moving ADSP to Hi… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Barry Leiba
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Alexey Melnikov
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bob Braden
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Procedural Changes through side-effect (was: Re: … John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Procedural Changes through side-effect (was: … S Moonesamy
- Spontaneous Procedure Invention ( was Re: Procedu… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy