Re: [ietf-822] A permission to re-sign header
Hector Santos <hsantos@isdg.net> Fri, 18 April 2014 15:22 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 80BFE1A03A1 for <ietf-822@ietfa.amsl.com>; Fri, 18 Apr 2014 08:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.879
X-Spam-Level:
X-Spam-Status: No, score=-97.879 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_16=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
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 8HjoTV7AW0sr for <ietf-822@ietfa.amsl.com>; Fri, 18 Apr 2014 08:22:23 -0700 (PDT)
Received: from ftp.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAAC1A01AF for <ietf-822@ietf.org>; Fri, 18 Apr 2014 08:22:22 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3260; t=1397834537; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NG+GMA555lLGbyGwzSYOOm+n5YM=; b=LRU7+eW5KLYWZdJCTjKW MuVo6GAoWJeCkvi0wYHliTUOcdpGICdNxa0MS6rcQcmOYZIC7DKJ4uBuyFq1lExQ PQrcn1tM2Mk3JrH9ZLyRQn88XYtxu+Bj4I8cN8IRZbl/zycBKuJA4uuabZdXmWFd arOThxFIAf67T/z1yqQ5C04=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Fri, 18 Apr 2014 11:22:17 -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 943111001.5072.3920; Fri, 18 Apr 2014 11:22:16 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3260; t=1397834463; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Pog3VD5 gAhvNKJVuT2ZFLcWSA9XjH28KD9x+FXTkS9s=; b=qr9hPBEth3yUJibweu3qFRr UuVnj75xvco7Pi2apBAontmFlLXUyKxU5goCNXx5VxMEVqd0BRiTYWNDuOvlGI0d TqEGfDZxk+xH+TQhUR1it+1poijOmz3iRkY487Ov7fTthIjuQyzXnUma15p5BetZ 95VUWczdTjaMka2yRgTk=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Fri, 18 Apr 2014 11:21:03 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 962639531.9.10184; Fri, 18 Apr 2014 11:21:02 -0400
Message-ID: <53514329.4060501@isdg.net>
Date: Fri, 18 Apr 2014 11:22:17 -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: ietf-822@ietf.org
References: <20140418123721.3610.qmail@joyce.lan>
In-Reply-To: <20140418123721.3610.qmail@joyce.lan>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/sJkUOCm6br_ACvFKvAco5OFyvq0
Subject: Re: [ietf-822] 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: Fri, 18 Apr 2014 15:22:27 -0000
John, Sounds reasonable so far, but the main issue is making the MLM honor such or any strict protocol logic. What happens if the policy is strict and does not allow for 3rd party resigning, i.e. no M-R header is provided by the originated and doesn't create them as well? Will the MLM honor the policy? Once the HARD FAILURE handling is a acceptable consideration , then we can have the energy again to revisit the already discussed possible solutions, including looking at why YAHOO did not do what DKIM wanted by looking up the SDID (d= tag value) against any existing whitelist or trust database to lead the way, in additional as to why not using the AUID (i= tag) for user level unique signing. The only real change for DMARC is to correctly lay out the 1st and 3rd party handling semantics given all the possible DMARC tag values between: p=none|quarantine|reject adkim==r|s aspf=r|s Is this sufficient? Why can't this M-R be described via the policy record? I think it would be with the p=reject and relaxed adkim=r and aspf=r alignment defaults. Unless I my (quick) reading the DMARC spec is wrong, the YAHOO policy currently has: p=reject adkim==r (not set, default) aspf=r (not set, default) As I understand DMARC, this means mail must be signed but it can be either a 1st and 3rd party signature. This would be the same as a ADSP DKIM=ALL policy. If so, maybe YAHOO is handling the logic wrong? I don't see the "alignment" requirement with the implicit default relax alignment adkim=r, aspf=r defined for their record. Maybe someone can explain where the "strict" alignment (5322.From.domain must equal the signer domain) is defined via yahoo's DMARC record and in the specification. Anyway, I think the basic problem is to first revisit the wider, practical POLICY SEMANTICS for 1st party and 3rd party operations and make the expected protocol handling draft corrections and/or clarifications. This is really about the MLM honoring STRICT policies, and also given the author domain the benefit of all doubt that their publicly exposed DMARC policy was well considered and published for a reason. We should treat all domains equally with the protocol, including yahoo.com. Thanks -- HLS On 4/18/2014 8:37 AM, John Levine wrote: >> Even with the local part (marissam) an M-R is not really hard to >> forge, otherwise DKIM-Signature wouldn't have had to include all the >> other tags. If we worry about replay attacks, we can enhance M-R so >> that it includes them too. For example, we could make M-R exactly >> like a regular DKIM-Signature, except that it would be a very very >> weak one, something that the MLM won't break. > > BTDT. If we could invent a weak signature that the MLM won't break, > we wouldn't have this problem. The M-R token is signed so it should > be impossible to forge, and we don't expect anyone to change it in > transit. > > I also note that this hack, with or without Ale's changes, does > nothing to solve the send from gmail and WSJ article problems. > > R's, > John > > _______________________________________________ > ietf-822 mailing list > ietf-822@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-822 > >
- [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