Return-Path: <doug.mtview@gmail.com>
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 9A7241A6FEF for <ietf-822@ietfa.amsl.com>;
 Wed, 30 Apr 2014 10:16:00 -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 2HpA3jtDK57Q for
 <ietf-822@ietfa.amsl.com>; Wed, 30 Apr 2014 10:15:59 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com
 [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id
 13D631A7030 for <ietf-822@ietf.org>; Wed, 30 Apr 2014 10:15:58 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id w10so661986pde.12 for
 <ietf-822@ietf.org>; Wed, 30 Apr 2014 10:15:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=me8UbRVGc9ZuQdrRPsqJHOle+d+jD+1V+cpjRRE6/pU=;
 b=IqOOAGG8O/m/lKBqiPyZqHK7TpBWcGh/amaLKb4ghqq2lZ8JK0OgmQTIAFQz5E0+mI
 D8Ra0NAOHWD1NHMRM7vSKjXsRKD/oRn81Mr7apGUqa239c6grUQs9v/rAwPO+QHXc+7G
 2bcXNxet2foYowDymi5R8ZPF/GtfaiQeNeAFuz3REXkm7Yq6aHNKRXtmR7jdlorP7dW5
 JnLgMixBCTZhGGbV9NGIEPWVLB3InDG34EcpoVgyOC1nrh6HQ7YMOTVUyFbQTK5BpIlM
 XlWIBrZ9REe38rhhiD2bxHRlXR0/TxS5PpygBj5wERSgv+IO9yqpNaHxzSCz3XD8Gn1M myIw==
X-Received: by 10.66.124.163 with SMTP id mj3mr10902652pab.38.1398878152460;
 Wed, 30 Apr 2014 10:15:52 -0700 (PDT)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net.
 [107.0.5.6]) by mx.google.com with ESMTPSA id
 vd8sm139354902pac.12.2014.04.30.10.15.50 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Wed, 30 Apr 2014 10:15:51 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <53611CCE.3010302@qti.qualcomm.com>
Date: Wed, 30 Apr 2014 10:15:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A85E07B-B4D8-4022-9142-38E5DF5D437E@gmail.com>
References: <535646AA.2080400@pscs.co.uk>
 <20140422202403.42908.qmail@joyce.lan> <01P6Y9IJSOEG000052@mauve.mrochek.com>
 <535B8B07.6090307@tana.it> <01P73EQM1PKQ000052@mauve.mrochek.com>
 <535BED95.6090304@tana.it> <01P73LU0RT9I000052@mauve.mrochek.com>
 <53611CCE.3010302@qti.qualcomm.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/2nWqTOsR-rBESE6Mo2K93jv8uwQ
Cc: ietf-822@ietf.org, Ned Freed <ned.freed@mrochek.com>,
 Alessandro Vesely <vesely@tana.it>
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: Wed, 30 Apr 2014 17:16:00 -0000

On Apr 30, 2014, at 8:54 AM, Pete Resnick <presnick@qti.qualcomm.com> =
wrote:

> On 4/26/14 10:56 AM, Ned Freed wrote:
>>>> I'd much rather pursue Pete's approach.
>>>>      =20
>>> I like it too, but I haven't fully grasped it.  On the 16th he =
wrote:
>>>          If the originator's site is going to allow that, you could =
create a
>>>     mechanism where the originator's site gets some sort of
>>>     cryptographic data from the mailing list site and include that =
in
>>>     its signed message, such that when the eventual recipient gets =
the
>>>     message, it can verify that it came from a mailing list site =
that
>>>     the originator explicitly sent the mail to.
>>> =
https://mailarchive.ietf.org/arch/msg/ietf/T823fjs5PWq2BjvOZ-FzZ5YMjSA
>>>       I assume the final message has a valid author's domain =
signature,
>>>  otherwise we need to modify DMARC.
>>>    =20
>> Or override it.
>>=20
>>  =20
>>> The only way I see is that the
>>> MLM, after message modification, sends the message or its hash back =
to
>>> the author's site to get it signed.  That sounds too complicated, so =
I
>>> must be missing something.
>>>    =20
>=20
> As I said to someone earlier, I take it that the author's site is =
allowing the author to have the mailing list resend a modified version =
of their message, whatever the modifications might be. So all that the =
mailing list needs is a short-lived token (probably signing the Date: =
and From: fields, maybe encrypted with the *mailing list site's* key), =
resigned by the mailing list site along with whatever the mailing list =
sees fit to sign, such that the eventual recipient can see that the =
message (a) came via the mailing list from the mailing list's site and =
(b) the mailing list got the message (some short time ago) from the =
author's site. That shouldn't require the mailing list to communicate =
with the author's site, but it might require the author's site to get =
something from the mailing list's site.
>=20
>> Perhaps it's time for a more concrete proposal to be written down.
>>  =20
>=20
> Ah, for a world with more time just to read these messages, let alone =
write down a proposal.
>=20
> If there are others who have a handle on what I'm thinking about and =
want to work on this, I'm happy to spin up a WG to work this out. =
There's no way I'm going to be able to hold the pen on this, but I think =
I hear sufficient motivation to get this done.

Dear Pete,

Expect a clean up of an older draft solving this problem without crypto =
tokens (except hash labels).  An authorization of some domain, verified =
in some fashion, with various constraints applied, in a way permitting =
retraction during abuse. This permits a chain of messages over multiple =
third-parties (very mailing-list friendly without tweaks to outbound =
servers).  It also seems however this is not the right mailing-list to =
discuss this alternative.

Regards,
Douglas Otis=