Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

Dave Crocker <dhc@dcrocker.net> Thu, 30 March 2017 23:15 UTC

Return-Path: <dhc@dcrocker.net>
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 D0344128B38 for <dmarc@ietfa.amsl.com>; Thu, 30 Mar 2017 16:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level:
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 uQKt2geK6HYX for <dmarc@ietfa.amsl.com>; Thu, 30 Mar 2017 16:15:51 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FD3126C23 for <dmarc@ietf.org>; Thu, 30 Mar 2017 16:15:44 -0700 (PDT)
Received: from [31.133.143.184] (dhcp-8fb8.meeting.ietf.org [31.133.143.184]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2UNHjtY030983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Mar 2017 16:17:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1490915867; bh=jTw/nJQJv+nZUUpnSi7xzIQMLsvukfJp+wjlkHsWQhM=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=Lip0NVlxhjgYHXLzikTeR7KAgGmlKSqk5mKDnhCqtBC79ZC0tbeslP4bUysvFsTKJ 9fmDh7QHrnxdCf35GKn0o/EJpQUxftWhe9eCtjVCOJJLJ4kHlBHBpM0pdKI83tc2KH INDYqoALwcXajaVmJ8FH3jFkFBeJKaHpvZr+iw9s=
To: ned+dmarc@mrochek.com, Peter Goldstein <peter@valimail.com>
References: <CANtLugO_D1Mz_v_341pc5O1mZ7RhOTrFA3+Ob5-onp72+5uRfA@mail.gmail.com> <alpine.OSX.2.20.1703272118210.2533@ary.local> <CAOj=BA0YKHYrkseR=wwgZn0_GNBKfdL7jmHehgBRzxqGKV6C1g@mail.gmail.com> <2978391.eJVbVTHBlo@kitterma-e6430> <CAL0qLwbP4c+09=TNSOsDqKwcp6iw++aGW8jDhARoVwvsghSLvA@mail.gmail.com> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <CAOj=BA3p-XQT=AeR4PHC-udWsn7rOmtR+UQHV0vbVofDKYOH_Q@mail.gmail.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, "dmarc@ietf.org" <dmarc@ietf.org>, Scott Kitterman <sklist@kitterman.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net>
Date: Thu, 30 Mar 2017 18:15:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <01QCKXW9MZ4Q0003XB@mauve.mrochek.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/SnWK0DipNAiOZl3sivIjt8kK4IA>
Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 30 Mar 2017 23:15:53 -0000

On 3/30/2017 12:13 PM, ned+dmarc@mrochek.com wrote:
> And given the relationship with DKIM people are going to expect ARC
> to work in the same general way, maing such a change a least astonishment
> principle violation.


+10.

This thread has been active for 6 days.  That is 5.5 days longer than it 
should have lasted, and I'm being generous.

Internet technologies succeed through interoperability testing, not 
conformance tests, or the like.  Conformance testing, and the like, are 
useful for early-stage bug-finding, but not for 'certification'.  This 
point has been a distinguishing feature of Internet technical work since 
before the Internet.

ARC is a small re-casting of DKIM.  DKIM has worked for quite a few 
years.  Some details of ARC need to be different from DKIM, but the 
basic paradigm -- including the model of achieving field operation 
through interoperability testing -- should be the same.

My reading of this too-long message thread is that there is essentially 
no support for making ARC's header-related issues any different from 
DKIM's, so I encourage the chair to shut this thread down.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net