Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03

"Murray S. Kucherawy" <> Sat, 03 November 2018 04:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02351130E2A; Fri, 2 Nov 2018 21:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0mjiZrhAfcFL; Fri, 2 Nov 2018 21:00:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D44AB130E4E; Fri, 2 Nov 2018 21:00:41 -0700 (PDT)
Received: by with SMTP id u6-v6so3429296ljd.1; Fri, 02 Nov 2018 21:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=PqAcz76qpb9iW8LpzkonpHmjs7IvN8oD6ztaFT97BJzL3RsY4H5nSFLjMcfsDMIuJn Bjbr66usOuPx3/5ZCBl20J4cNW26fsM2HaTL4SEMmyypfqXpCDML0eVx65zslBG7Gp1f QTuJg9qhJYLrt95aro0hyVLLjGCNMtkgZXUjr9HatA6zGnSsRgvJV49aUmUU7AjNfgQu nQbbYVEvUtLD+ZP7TJ//ZsZZXDAyGn530umdkHlddAOQ/NUkn2xPTZtedn8NHPO5DrHK as+OhL30sDwEftTOuzIGb+q1xZnqpQKMOGfBoEnDmpQX3YhHEgZVB43YQYpmvtSBgf0S 1DMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=GuNz5wLB2oVBD754uu+5c2yOjGO8koF4jN2wk/grD1PYjKCA8kjZTcQi0dOlMkerJ6 LQr4zY7Brt0JO7feIqD1684ArYzU+h4V3cjPEiVZHvVjxnjo4BTYlV6dDRsIaif5zM+p 9lw1MGROTTxb0BZMf8h+vspcTQu6uCaXojBhbeRO5z/SI6btaw4b3t8vCDsgqy3ZSFfH bQR7yRTACf7GAXgvaHpLB2prXwKsNabdjKD65vP9TYK0+XQJ/ljd6LzeGIgdBhZtvFTW mR0w27DTQr/UXoEuuhklD/E0LYKUuXUKxon0fdigNPju/03fz/p0Pqx8ERsxcGtJbl8+ EAvQ==
X-Gm-Message-State: AGRZ1gJaMKA1XlZK7NJ6mWtfmbLv869zb68RE+XHi3C8TBBvk2C/uUUw rWGIoMU82q3UAVNT3RLzew9yFZwNWcmeLDrXE2Y=
X-Google-Smtp-Source: AJdET5faygPzBYA21nG7Q678YA6C+lVW60rX7ESr/lGwb/dIW32ZsCHHm7Nl1aRVN5ukV+xU3vBdS1HMWiclHf2CMFU=
X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr9054104ljc.141.1541217639751; Fri, 02 Nov 2018 21:00:39 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sat, 03 Nov 2018 13:00:27 +0900
Message-ID: <>
Cc:, IETF DMARC WG <>,, ietf <>
Content-Type: multipart/alternative; boundary="000000000000f066ad0579bab1da"
Archived-At: <>
Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Nov 2018 04:00:54 -0000

On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <>

> Section 7.1.  Forged Header Fields
> In addition to a recommended solution, this section has list a potential
> alternative solutions which the document then states that it is not
> appropriate
> for this document to specify which mechanism should be used.
> Since an implementer is not expected to do anything with this information,
> it
> might be more appropriate for this to be moved to an appendix at the end
> of
> document.

Implementers need to be aware of these things in order to make informed
handling decisions, but we also acknowledge that we can't propose a single
solution that will work for all operational environments.  That's what this
text means to convey.

By my read of RFC3552, that's what this section is for, rather than an

Section 7.2.  Misleading Results, First paragraph, last sentence
>    "In particular, this issue is not resolved by forged header field
> removal
>    discussed above."
> which seems to be in conflict with the following statement from section 5:
>    "For simplicity and maximum security, a border MTA could remove all
>    instances of this header field on mail crossing into its trust
>    boundary."

They're not in conflict.  Even if I remove all instances of this header
field at ingress and then evaluate DKIM (for example), I have no idea if a
valid signature from "" should be interpreted such that I trust
that message more (or less).

The two paragraphs you're talking about solve different problems.

> Section 7.2.  Misleading Results, Second paragraph
>    "Hence, MUAs and downstream filters must take some care with use of
>    this header even after possibly malicious headers are scrubbed."
> How do you expect an MUA or downstream filter to act on "take some care"?
> Can you elaborate on that?

If you are a spammer or malware distributor, you can elicit a DKIM "pass"
by simply creating your own domain and signing your bad email with that
domain.  The fact that you got a "pass" doesn't tell you anything about
which domain's signature succeeded, nor does it confirm the message content
is safe or trustworthy in any way.

"take some care" means "keep this in mind while deciding how to render a
message to end users, who might not know to even look at this".

7.3.  Header Field Position
> This section explains that headers fields are *not* guaranteed to be in a
> specific order. The section then states that "there will be *some*
> indication..."
> Since the order is not guaranteed, what do you expect an implementer to
> take
> away from this?

"in the general case" and "but most do not".

So: Most of the time, you can rely on header field ordering to determine
the sequence of handling.  You are at least certain about whether you can
trust the tail end of that, because you know your own environment from the
ingress point.

7.8.  Intentionally Malformed Header Fields
> This is a general issue with any header. Is there anything specific to
> this
> header that an implementer should pay attention to?

No, not really, but at the time this text was originally written (see
RFC5451; this is about the fourth version of this material), it was felt
this was worth adding.