Re: [ietf-822] one can re-sign without a permission to re-sign header
Hector Santos <hsantos@isdg.net> Sat, 03 May 2014 16:43 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE331A0109 for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 09:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable
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 Q0G9Ny2W3V3I for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 09:43:06 -0700 (PDT)
Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CF3101A00F4 for <ietf-822@ietf.org>; Sat, 3 May 2014 09:43:05 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4239; t=1399135375; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XoO49fPixMDIRTZv5F36+u9oR3g=; b=Cw/z3vjOU/X7msvlDT5u 1dz9092IALANiDOTyeh5RRjHP9UTM+1yiJE/XXzIIZOhvnXW4kZQZOggPwWanpY7 XGOTwG+RENnoMBSyJeWAxeRMe5sSTwtGkGVWDa9UCe8XFBDBbdeHsq/1Cs5+zJnA reXt5rANah5xZLUg90SsQp4=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Sat, 03 May 2014 12:42:55 -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 opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2243933107.3325.3136; Sat, 03 May 2014 12:42:53 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4239; t=1399135275; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JA+Cas3 V6tOE041IJ0kceadS8nHkX2YdW6cNaCO50BE=; b=1Hu1IdX+1FieI4TXe5PNMkS kBfTSIoLWflqSrD8tDeCN40EvGGFkQQ3aO7qu5NnDSKucrlxoma1F4yn8xTSdlFA BmGOS5i141WLjcSMn6Sw6oiMeUlFx9rYemWx9CC+3Hljwr3+1YJuouMtwB6Q0YhV zD5A9yqi+YKEJ+o9y6fA=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Sat, 03 May 2014 12:41:15 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2263451406.9.14260; Sat, 03 May 2014 12:41:14 -0400
Message-ID: <53651C91.70501@isdg.net>
Date: Sat, 03 May 2014 12:42:57 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Douglas Otis <doug.mtview@gmail.com>
References: <20140501195449.68225.qmail@joyce.lan> <5363ACA6.1010203@qti.qualcomm.com> <alpine.BSF.2.00.1405021036010.79573@joyce.lan> <5363CB57.4030505@isdg.net> <465A7B8E-7E37-4B0D-BF6C-FA49CB7C0DA9@gmail.com>
In-Reply-To: <465A7B8E-7E37-4B0D-BF6C-FA49CB7C0DA9@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/iD8t6Pbl3eJORz57TmSAzdgFf2Y
Cc: ietf-822@ietf.org, "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [ietf-822] one can re-sign without a permission to re-sign header
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 16:43:08 -0000
On 5/2/2014 1:09 PM, Douglas Otis wrote: > Dear Hector, > > I hope you are willing to review a TPA draft. Doug, I did go over your drafts in 2009 when it was rev3. I see I even explored compiling your C code under Windows to create labels: Directory of M:\rfc\dkim 10/12/2009 10:45 PM 39,185 draft-otis-dkim-tpa-label-03.txt 10/17/2009 08:44 AM 7,175 tpa3.cpp 10/17/2009 08:44 AM 16,384 tpa3.exe I don't know how much rev6 changed, but as I recalled mentioning to you in 2009, there was too much details to follow but it was definitely a much wider scope and coverage. But we all had the same basic idea and fundamental problem of an authorized 3rd party (re)signer need, whether it was with: SSP Sender Signer Practices ADSP Author Domain Signer Practices (RFC5617) ASL ADSP extension for 3rd party (smaller scale) ATPS ADSP extension for 3rd party (RFC6541) (larger scale) TPA ADSP extension for 3rd party (wider scope, large scale) The technical problem was how to best do this via DNS, the scaling and optimization with a plug and play DKIM security policy layer as it was originally envisioned. The practical problem was to how convince publishers and verifiers, especially resigners, to support and also enforce the stronger, restrictive policies as a deterministic mail filter. It was made a harder problem with the interest of the 3rd party resigner became more important than the interest of the originating author domain. This was burned in RFC5016 Section 5.3 Item 10 functional requirements. IMO, that needs to be corrected and not carried over to any future signing practice requirements or specifications doc. That is not to suggest local policy does not prevail in any situation, but it would be the first security protocol principle to support the highest domain protection payoff value a security protocol has to offer over all any other modes of operations. You can't just intentionally ignore it knowing full well what the purpose of the security policy protocol was designed to do. So I think we need to revisit the functional requirements for a DKIM Sender/Author Signing Practice protocol. I believe this will help update DMARC or any other "improved DMARC" that comes down the road. We need to revisit the basic process model DKIM framework for both POLICY and TRUST where a: - Message comes in, - Verifier Check Author Domain Policy, - Verifier Check Signer Trust Policy. Just like the RFC5585 DKIM Service Overview illustrates and outlines in Figure 1: | |- RFC5322 Message V +--------+ +--------------------------------+ | Private| | ORIGINATING OR RELAYING ADMD | | Key +...>| Sign Message with SDID | | Store | +---------------+----------------+ +--------+ | (paired) [Internet] +--------+ | +-----------+ | Public | +--------------------------------+ | Remote | | Key | | RELAYING OR DELIVERING ADMD | | Sender | | Store | | Message Signed? | | Practices | +----+---+ +-----+--------------------+-----+ +-----+-----+ . |yes |no . . V | . . +-------------+ | . +.......>| Verify +--------+ | . | Signature | | | . +------+------+ | | . pass| fail| | . V | | . +-------------+ | | . | | | | . +.......>| Assessments | | | . . | | V V . . +-----+--+----+ +-------+ . . | | / Check \<............+ . | +-------->/ Signing \ . | / Practices \<..........+ . | +-------+-------+ . . | | . . | V . +----+--------+ | +-----------+ +------+-----+ |Reputation/ | | | Message | | Local Info | |Accreditation| +----------->| Filtering | | on Sender | |Info | | Engine | | Practices | +-------------+ +-----------+ +------------+ Figure 1: DKIM Service Architecture So the framework was laid out. We just need to get folks to support the Check Signing Practice (CSP) module and also honor the policy. The "Local Info On Sender Practices" module is what John Levine wants people to do, including a whitelist. Thats fine, but it wouldn't be a consistent and persistent result across SMTP receiver sites unless they had the same local information. Even if this WhiteList was centralized, it should still check and honor how restrictive the domain policy is. -- HLS
- [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] A permission to re-sign header Hector Santos
- Re: [ietf-822] A permission to re-sign header Murray S. Kucherawy
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Murray S. Kucherawy
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Michael Richardson
- Re: [ietf-822] A permission to re-sign header Michael Richardson
- Re: [ietf-822] A permission to re-sign header Theodore Ts'o
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header Miles Fidelman
- Re: [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] one can re-sign without a permissi… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Ned Freed
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Paul Smith
- Re: [ietf-822] don't need a permission to re-sign… John Levine
- Re: [ietf-822] don't need a permission to re-sign… Ned Freed
- Re: [ietf-822] don't need a permission to re-sign… John R Levine
- Re: [ietf-822] don't need a permission to re-sign… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Pete Resnick
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- [ietf-822] We need a DKIM Policy Working Group Hector Santos
- Re: [ietf-822] We need a DKIM Policy Working Group S Moonesamy
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- Re: [ietf-822] one can re-sign without a permissi… Pete Resnick
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Paul Smith
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- [ietf-822] WSJ/gmail/ML, was a permission to... Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Rolf E. Sonneveld
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Dave Crocker
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Bart Schaefer
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] one can re-sign without a permissi… Brandon Long
- Re: [ietf-822] one can re-sign without a permissi… Murray S. Kucherawy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Scott Kitterman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] one can re-sign without a permissi… Murray S. Kucherawy
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs S Moonesamy
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs S Moonesamy
- Re: [ietf-822] Aptness of DKIM for MLs Hector Santos
- Re: [ietf-822] Aptness of DKIM for MLs Douglas Otis
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs Douglas Otis
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Douglas Otis
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis