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 16:43 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 A321312867A for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 08:43:27 -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 TbWUBBGy5yoz for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 08:43:26 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 90590128B01 for <dmarc@ietf.org>; Sun, 6 Jan 2019 08:43:22 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id b20so28497009lfa.12 for <dmarc@ietf.org>; Sun, 06 Jan 2019 08:43:22 -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=Z7rE5WNgiJMYSSoBi0vR9cqkG5OEpyL1UCmvG1hbdh8=; b=Dh+ApcQ3jXXZehs46xSCoxdNk81JuLeBGNjzVJQb6wJ0o7T7isTiZcIJ1dGsPL3TBF uIygzKvWXm0dhH20FcxGVei0adjCo2dqn3EWLfXH8Eioc5Lc1ksHH4AioaGSXGq09Ce4 LzYbDXXDXWVG+qrFMUJdVDJ8SSpk49LH4XRCrtrrbkBkqK3HPU8lGhNKJfiDeqYVq4ON H1HQ+YwXOyW/PLyLhWcGvOcmOAj5hsMxPnvsbvN3xPsZ4f/J0AXWhVBiOOWYVh295Wrw 7uXVCuxA09hM+ENyvQyw+1g17W3nsBIpw7lnu7452bm/GP/dJIvwGuCf997vHil2Lneg Y7sw==
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=Z7rE5WNgiJMYSSoBi0vR9cqkG5OEpyL1UCmvG1hbdh8=; b=l09Y/YHbnUyF0MlP6pTBKQ9dZ6M20Umm/JORkb9+s9eZ9YDupBbiTPiiQlG9XT1r1K O4KZ8wkVAQt6/ZQntqGbli1Hwa7P76LPuxTfN73r9U3VNtgIMuj/dKOIxi71Uut3UGHJ kZt4pP/mw3ebawsO0SicVanobWx17UDPpDnzkMJH1oTT1KSabnzL9EDiryuhX1zAZln8 nL6+3m9E7Vuwv1tWeP63KEKv8rJUaOQr8mzJpoqGBWbRInCwCddgwdvSFInJl5xMZ7Q5 IaQ5gVh6X7houTlP2VsAFkxrZxghNJsk1cmo+UECbEOkunWohoKs00kbbcTTZ55z8xkB nznQ==
X-Gm-Message-State: AA+aEWZ65IBD3Vid0f5sQXrSnhUG4f/XFcQc9AhmouwbVLW0+LN9+y5H 3KxeeLOCoyleZQmimSWHz9+7SlwYR41r9KvbZ0O+Yw==
X-Google-Smtp-Source: AFSGD/X2+0UR+uCMddxEG9puTWGje3thJNmXQWlzqZkweUS9EuTV1hBilTMBswAN1IyvPnlcPyxUc6rak17Q4j8e0X8=
X-Received: by 2002:a19:a9d2:: with SMTP id s201mr27615680lfe.154.1546793000510; Sun, 06 Jan 2019 08:43:20 -0800 (PST)
MIME-Version: 1.0
References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> <CAL0qLwbo6Obzq7d4c=tzBJi61-1RPb6UO8KKkwmex=GV7zf7PA@mail.gmail.com>
In-Reply-To: <CAL0qLwbo6Obzq7d4c=tzBJi61-1RPb6UO8KKkwmex=GV7zf7PA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 6 Jan 2019 08:42:42 -0800
Message-ID: <CABcZeBPbEd6hRyzJv9JP-NwiTZG_VtEQ+Y2osyorkC4B-q7-4A@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: The IESG <iesg@ietf.org>, Tim Draegen <tim@dmarcian.com>, IETF DMARC WG <dmarc@ietf.org>, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000564554057ecccf94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/iEQBaysW7EEldR4mavnnlm1_syE>
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 16:43:28 -0000

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, 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.

>
> 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.


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.


S 2.2.
>> >      combination of these can be applied.
>> >
>> >   2.2.  Formal Definition
>> >
>> >      Formally, the header field is specified as follows using Augmented
>> >      Backus-Naur Form ([ABNF]):
>>
>> An example would be kind of helpful here.
>>
>
> I put in a forward reference to the Examples section instead.
>
> S 2.4.
>> >
>> >      This ptype existed in the original specification for this header
>> >      field, but without a complete description or example of intended
>> use.
>> >      As a result, it has not seen any practical use to date that matches
>> >      its intended purpose.  These added details are provided to guide
>> >      implementers toward proper use.
>>
>> This text is odd in a bis draft, because "the original" is not 7601 or
>> 7001.
>>
>
> Would actual RFC numbers be better?  The point here is that the original
> (5451) didn't do a great job of explaining how this works, and then the
> intervening versions (7001, 7601) didn't fix it.  We're finally fixing it
> here.
>

Yeah, I think RFC #s would be better...

-Ekr


> -MSK
>