Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: <draft-ietf-dmarc-arc-protocol-18.txt>...)

Scott Kitterman <sklist@kitterman.com> Mon, 05 November 2018 05:25 UTC

Return-Path: <sklist@kitterman.com>
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 2074B128A6E for <dmarc@ietfa.amsl.com>; Sun, 4 Nov 2018 21:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=A+cC3rt7; dkim=pass (2048-bit key) header.d=kitterman.com header.b=SywBTRMB
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 o7e5lWhZKqoS for <dmarc@ietfa.amsl.com>; Sun, 4 Nov 2018 21:25:28 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068D71277C8 for <dmarc@ietf.org>; Sun, 4 Nov 2018 21:25:28 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541395526; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KAWP6bT6y5gBQWanT5bEEyHpDnlYcUOaXpu+w5hHEVU=; b=A+cC3rt7Ml0/IXxJuKQOrmLfvXFIvW3oSN4LXZ0WOGc2V9qmzr77TQaa tejQkmx5hdEr3+8EWdwnIbFFC+7TDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541395525; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KAWP6bT6y5gBQWanT5bEEyHpDnlYcUOaXpu+w5hHEVU=; b=SywBTRMBXWmEXJFNONWcNyoNah24XwaYnuHBU5N9ltpQp0Alfdc2p96x GeTXP5uyHoqGV4T/0UrD3DoUo2hsxVlaTPVYfM0k0XbWnqSbGFsXE7jCxZ pRUdbv6+H0Beo94ku+Y8zj+aXjY8BtRUSzDEATsVv9FHkyTD72k2qMUwGL RpzLsXWRa7B1lavlM8NQL+a5m95eBKv8B5musvmc6XwSVC/yMr9DhCg3AZ pH++ENO524L0bF0CnETrA9OTzpeo9sYpKeDPur/MtCrebvN2jC1SPgAYqZ tfcAzATJFLcHRdNkHARad17Nj4KHOrdlDP86/PwRGG6HfifmaWCSqw==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB124C400D3 for <dmarc@ietf.org>; Sun, 4 Nov 2018 23:25:25 -0600 (CST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Mon, 05 Nov 2018 00:25:24 -0500
Message-ID: <4082068.TRYGpCgONJ@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAL0qLwbAaT6P6NUJC=j8Vg47Vd01ktR8xU7=D1JXZTcfTFdd0w@mail.gmail.com>
References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <A80F2CA9-7E97-49CB-87A6-C406C8002B6E@kitterman.com> <CAL0qLwbAaT6P6NUJC=j8Vg47Vd01ktR8xU7=D1JXZTcfTFdd0w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/J_WLXIfxAVShBXJ-MF-W1OlcAD8>
Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: <draft-ietf-dmarc-arc-protocol-18.txt>...)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 05 Nov 2018 05:25:30 -0000

I don't think it's something we should delay on.  In my, admittedly limited, 
experience with these things, once something is in an experimental version of 
an RFC, then it 'has' to be preserved in the name of interoperability with the 
installed base.  I think now is the time to remove obvious fluff.  This 
documents makes my head hurt enough as it is.

If anything, it should be a separate document as it's got nothing to do with 
ARC, per se.  Any utility of AMS past the immediate previous one is entirely 
speculative.  Let's lean towards easy, not hard.  Now is the time to prune 
this.

Having reviewed the thread that Kurt pointed me to, it seemed like this is 
something only one person wanted.  It didn't appear to have a lot of push 
behind it.

Scott K

On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote:
> Given the intended status is Experimental, is this something that's a
> showstopper?
> 
> We have the debate about "fail" versus "invalid" that I believe we consider
> to be a showstopper for Proposed Standard, but we're willing to let slide
> for Experimental.  Is this the same?
> 
> -MSK
> 
> On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman <sklist@kitterman.com> wrote:
> > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <kurta@drkurt.com>
> > 
> > wrote:
> > >Taking this back to the dmarc list instead of the IETF-wide one:
> > >
> > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <scott@kitterman.com>
> > >
> > >wrote:
> > >> . . .  I understand the desire to just ship it at this point so more
> > >> operational experience can be gained before another update.  With one
> > >> exception, I agree with that approach.
> > >> 
> > >> In Section 5.2.  Validator Actions, I think it's highly unlikely that
> > >
> > >Step
> > >
> > >> 5, AMS (ARC Message Structure) validation of AMS header fields beyond
> > >
> > >the
> > >
> > >> one immediately prior in the chain is useful.
> > >> 
> > >> Failure doesn't change the ARC result, so there are no
> > >
> > >interoperability
> > >
> > >> implications for removing it from the draft.  The only reason to
> > >
> > >specify
> > >
> > >> anything is the notion of 'oldest-pass'.  This looks like a dubious
> > >
> > >and
> > >
> > >> premature optimization to me.
> > >> 
> > >> I didn't and don't plan to implement it.
> > >> 
> > >> Later, after there is more experience with ARC, if it's established
> > >
> > >that
> > >
> > >> validation of AMS beyond the immediately prior step in the chain has
> > >> utility and there is sufficient efficiency associated with
> > >
> > >'oldest-pass',
> > >
> > >> it can be added then.  'Oldest-pass' seems like an easy way to get
> > >
> > >around
> > >
> > >> having downstream validators do AMS validation up the chain (by
> > >
> > >always
> > >
> > >> adding arc.oldest-pass=1 to all messages).
> > >> 
> > >> ARC is complicated enough without this and it seems like any easy win
> > >
> > >for
> > >
> > >> simplicity in design to take this out for now (and we'll see about
> > >
> > >the
> > >
> > >> future).  Deleting it also reduces the IANA considerations.
> > >
> > >I'm not by any means arguing with your analysis and plans to skip this
> > >component, but I did want to point you, for informational purposes to
> > >the
> > >WG thread which was the genesis of this concept. It was originally
> > >proposed
> > >as "closest-fail" but then inverted to be "oldest-pass". You can find
> > >the
> > >thread from January 2018 at
> > >https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI
> > >which references an older discussion circa August 2017.
> > 
> > Thanks.  I've reviewed it and my opinion is reinforced.  It ought to be
> > removed.  Nothing other than the immediate prior AMS matters for
> > evaluation
> > of the ARC result.  Everything about prior hops is purely for receiver
> > edification, not needed for the protocol.
> > 
> > Scott K
> > 
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc