Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Sun, 06 January 2019 20:14 UTC

Return-Path: <ekr@rtfm.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 A99A6130DF5 for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 12:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 XdMPGa5lvMrW for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 12:14:02 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D209130DEF for <dmarc@ietf.org>; Sun, 6 Jan 2019 12:13:58 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id p6so28765975lfc.1 for <dmarc@ietf.org>; Sun, 06 Jan 2019 12:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2OL6NZEIsrzfo3s6mtWUi/qYM4YEkMjbiBcu8CkL+9M=; b=MO/lbYb3s0zPKsmmgwjKIgB2X2Wmuq8T2FQ4zdDIC+nI7kf/1p32mDfUWZHEnjjW5I NgorpgfqmAK2U90wAIGXPKUcRI7uVAEj9N93bcVcCPthpxlpPwtahXlDvtcQjQAKaLGD 7k4UFiWFAommSJGzp69/7ZpHL6Ts0CsBkk109KYMkz+TAZ4urKRnV6T90zwRn2CK183v k7VTb+E9xvfMsvfXBlIUHdTPwQf5ybYvgmIR7sxInHgPGJHoCMX7aU8pAAouLe/om9R7 XsraTT2JqXzcR+CAuXqPk23xhvWEwtYep2FC9RTkcmdTWVmK1VGe/+l33vlb0SrlkzIt 3E6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2OL6NZEIsrzfo3s6mtWUi/qYM4YEkMjbiBcu8CkL+9M=; b=LA6PGJ8kFkOY6Wpsny5bOldSFWCYRMEnirmljaMXwzaEqhYaqgAFnWFQuHhOl/qNeg 9ChK7OsOzBxlF/mjenVOTAnPUAoxko4kWgkaCHi5nfybXhsuKHa720Kfo+7PVmYwaLCV RyMWEAuVxT6pe/vsJSx/n7d+Yaip5skCJj71zhLmVj0lnNpo5dtDyS28tVN+BuSWSO9l mt4O4sN/2wwVPZ7lG82xE1pjwSQjCmXl9Nn3MNqHiJvvgkxY69iAWRKw6ZLeibqU1le2 HbcowB9GjkTgnajY/DYcn67FMnUg5bNaxEKH3c9R+1AdX5CNjL8GmU+fldxP2KTHq5f0 5Elw==
X-Gm-Message-State: AA+aEWagfu7qWhS93iQkSSAC4GXXl5yYEv3R8q6hnFlHxgLcos+C9gQA ToCXz3a5KCIJPpXO+wB8JjKAjm8TvYSBqP6WsTUMFg==
X-Google-Smtp-Source: AFSGD/V+I1YQOV85Ewad3mmpbBWy1qFVcy8AXl5uMbhuPUdHx0+qKb0ioVixJ3m0yCabBPV9npuSdEyrYi6/vEkxh5o=
X-Received: by 2002:a19:910d:: with SMTP id t13mr27448163lfd.98.1546805636240; Sun, 06 Jan 2019 12:13:56 -0800 (PST)
MIME-Version: 1.0
References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> <CAL0qLwbo6Obzq7d4c=tzBJi61-1RPb6UO8KKkwmex=GV7zf7PA@mail.gmail.com> <CABcZeBPbEd6hRyzJv9JP-NwiTZG_VtEQ+Y2osyorkC4B-q7-4A@mail.gmail.com> <01R1OU11IFIK00004L@mauve.mrochek.com>
In-Reply-To: <01R1OU11IFIK00004L@mauve.mrochek.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 6 Jan 2019 12:13:17 -0800
Message-ID: <CABcZeBO5nAsH0VBD5jf+sD5HUdV+=bC7=ET4Z-8YvopSHGL50w@mail.gmail.com>
To: Ned Freed <ned.freed@mrochek.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, Tim Draegen <tim@dmarcian.com>, IETF DMARC WG <dmarc@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007c45d3057ecfc0bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/SRJkgnSo6n0nt7giwZ2Pu2_ivzQ>
Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)
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: Sun, 06 Jan 2019 20:14:05 -0000

On Sun, Jan 6, 2019 at 11:10 AM Ned Freed <ned.freed@mrochek.com> wrote:

> > On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <superuser@gmail.com>
> > wrote:
>
> > > Hi Eric, thanks for your comments and sorry for the delay in replying.
> > >
> > > I've applied all of your comments except those below, for discussion:
> > >
> > > On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > >>
> > >> IMPORTANT
> > >> S 7.10.
> > >> >      processing of these is outside of the intended scope of this
> > >> document
> > >> >      (see Section 1.3), some early guidance to MUA developers is
> > >> >      appropriate here.
> > >> >
> > >> >      Since MTAs are unlikely to strip Authentication-Results header
> > >> fields
> > >> >      after mailbox delivery,
>
> This sentence seems nonsensical to me: A message that has undergone
> delivery is by definition out of the MTA's hands - this is an essential
> part of delivery semantics.
>
> Now, if you're talking about what MTAs do before, as opposed to after,
> delivery, or submitting a previously delivered messge, or submitting a
> message
> part from a previously delivered message, or submitting a new message
> containing content extracted from a previously delivered message, then you
> need
> to be clear that's what you mean. But in the submission cases I'll note
> that
> it's not unlikely that Authentication-Results fields at the top of such a
> message will be removed by the submission process.
>
> > MUAs are advised in Section 4.1 to ignore
> > >>
> > >> I think you want to be stronger than "are advised to"
> > >>
> > >
> > > I changed "advised" to "warned"; is that adequate?  It's referring to a
> > > SHOULD in 4.1.
> > >
>
> > What I am thinking is that this should be normative language.
>
> Whereas I'm thinking that this is poor advice in general and should either
> be
> more tightly qualified or removed.
>

I could also live with that. I don't really have a substantive opinion here
about this
advice, I'm just trying to avoid having language which sort of exhorts
people
do to things, but not really.

-Ekr


> The problem is that there are many different reasons for exacting an
> encapsulated message, and the optimum handling of header fields varies
> dependin on the reason.
>
> If the intention is, say, to "burst" a mailing list digest into its
> component
> messages, since these fields cannot be asumed to have been
> generated by a trusted agent, whereas top-level Authentication-Results:
> fields
> may have some trust associated with them, then by all means remove the
> fields.
>
> However, if the digest was constucted from previously delivered messages
> with trusted Authentication-Results fields, retaining them is OK and may
> even be of value.
>
> And if the the intent is to use the messages as input to some sort of
> security
> scanning process, removing them may actually have an adverse effect.
>
> There are undoubtedly many other cases that arise, but I think this
> demonstrates the point.
>
> Of course having a simple rule would be nice. But there's no simple rule
> for deciding where the boundary between trusted and untrusted Received:
> fields lies - something which already complicates the handling of extracted
> messages - and we manage to deal with that all the time.
>
> > >
> > > S 1.2.
> > >> >      Thus, this document defines a "trust boundary" as the
> delineation
> > >> >      between "external" and "internal" entities.  Services that are
> > >> >      internal -- within the trust boundary -- are provided by the
> ADMD's
> > >> >      infrastructure for its users.  Those that are external are
> outside
> > >> of
> > >> >      the authority of the ADMD.  By this definition, hosts that are
> > >> within
> > >> >      a trust boundary are subject to the ADMD's authority and
> policies,
> > >>
> > >> This seems like a reasonable design, but not the only one. For
> > >> instance, Gmail might attach these headers, but I don't think of my
> > >> MUA as being subject to its authority and policies.
> > >>
> > >
> > > The MUA in the Gmail case is Gmail itself, isn't it?  Or at least their
> > > client?  Or are you referring to some IMAP access to it?
> > >
>
> > Yes. Like what I have on my phone.
>
> Indeed. IMAP and POP in the MSP case are a bit at odds with the simple
> ADMD model. That said, I'm not entirely sure what can be done about it
> that will clarify rather than further obscure the picture.
>
> > S 1.5.3.
> > >> >      agents, assign (some) responsibility for the message (which
> implies
> > >> >      authorization), and ensure that the listed portions of the
> message
> > >> >      were not modified in transit.  Since the signatures are not
> tied to
> > >> >      SMTP connections, they can be added by either the ADMD of
> origin,
> > >> >      intermediate ADMDs (such as a mailing list server), other
> handling
> > >> >      agents, or any combination.
> > >>
> > >> I'm not sure how persuaded I am by this terminology. However,
> > >> regardless of that, this claim about SPF seems problematic in the
> > >> sense that you could have an intermediate MTA decorate the message
> > >> with the incoming IP address (in some unspecified way)  but then have
> > >> the terminal MTA do the SPF validation.
> > >>
> > >
> > > Right, that's a property of SPF: It only evaluates the latest
> > > ("connecting" in that paragraph) hop, while DKIM often survives
> end-to-end
> > > irrespective of who's relaying it in to the local ADMD.
> > >
>
> > Hmm.. I think I'm making a different argument here. If the evaluating
> ADMD
> > trust claims made by a relaying hop, then it is able to do its own SPF
> > evaluation by having the relaying hop supply the IP address of the
> > originating MTA, even if the relaying hop didn't itself do SPF
> validation.
> > In this sense, it's not tied to the incoming connection.
>
> Quite right. And these sorts of arrangements where IP address information
> is derived not from the connection but from a Received: field, XCLIENT
> command, etc. are actually pretty common.
>
>                                 Ned
>