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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 05 November 2018 04:04 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E0A12D4E9; Sun, 4 Nov 2018 20:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qE0T0v9knHxi; Sun, 4 Nov 2018 20:04:20 -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 0E6E9128CF2; Sun, 4 Nov 2018 20:04:20 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id m18-v6so5091210lfl.11; Sun, 04 Nov 2018 20:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=n4rzJKPnjZafdxiBYPprQosuuzQccyGIAbMWuOt30asaF3qIR7c/K8bcSIfXG/NUCn 2q0Va4KJSKd8skA/K2Q0T85vn4VbPJXUnucEEhSBOqu9kchL2Glx00zk2vuBdV7Fl/Fv 9Gg+GJnz9d8jRlLqaH2liIhuWJCh9c7NAIemS2p40xU5s38GkDipf/480ElWycirbQeo R6m3escXeTH4jHdJTq0UpvLLlnTVMWW2VjAuzE1PT1p/7nfKYUr3IJ/PD2+zyvWbTZlt fuzB0UnE2p2I6229GNvoVg6/B31KSD6K6IjeRzBJy02sBiKwBxhVlDDy080W03idM/Bk Y5iA==
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=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=TwJfB8djK1lWAgVlsCeUVrkfA2yi1dQVM/m1oPN98PC+l8wC3d7UzoJ6LqTn4Dq3t4 JOx53wT8YNzcdcwk+I2gm8lLOKRsRuyexHilZ7sZhMt7kvPJXehyXnNLHoc6IpkIB9Xg sIxST9z7nlH8ldfNVdfkajKLSRLPVPGp4j5E+uNkAF9sNICY5D/rbDsQNSUOlWKszjej 5OXAls0hJioib1GXODzyHWdt6WjB3zhGRwaf525EYjj4mp5ZBPECWD9ZvNMx2nAFSTwT Hc9o5KGMZVuag10tB4mehAcmWgShWp/Hrl3N4c2t/zcHKILlSWBQoAxWlHDYpMaNBllH 51OA==
X-Gm-Message-State: AGRZ1gJ6vYEvaSnmGgoRvzENeHTI6minbZMZSnFaURdC8wWn3w03WTYL ml8ofjnrRjJzZYZlZ50BLrcmxYW3AV7oxfs3Rno=
X-Google-Smtp-Source: AJdET5evdvNHfYRumq8IYIaT12bk7fswQ20Kb7sp+vyJhxBA8lAr2eRYYCtNUgPwLnsdWCf7+UOC7+vxyPD2w3giECA=
X-Received: by 2002:a19:4948:: with SMTP id l8-v6mr10851228lfj.16.1541390658077; Sun, 04 Nov 2018 20:04:18 -0800 (PST)
MIME-Version: 1.0
References: <154100859354.5360.795312478907721541@ietfa.amsl.com> <CAL0qLwYoPy5FNx4rEW4NOKPHyPjfmW6OCYANnkeFUjjuvZQHrg@mail.gmail.com> <CAGL6ep+sX8sWf=G20gXMmKHAPua82gT+mwBq9cLSr46rC9tApg@mail.gmail.com>
In-Reply-To: <CAGL6ep+sX8sWf=G20gXMmKHAPua82gT+mwBq9cLSr46rC9tApg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 5 Nov 2018 13:04:04 +0900
Message-ID: <CAL0qLwaeorZD4KphPR15ccPeQ8JcGvH3ADGTqBUeAekTy-QSWw@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: secdir@ietf.org, IETF DMARC WG <dmarc@ietf.org>, draft-ietf-dmarc-rfc7601bis.all@ietf.org, ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a289020579e2fa72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/o2sjE9C_U7wHT9BrxXMHiQdcx9c>
Subject: Re: [secdir] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 04:04:22 -0000

On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
wrote:

> 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".
>>
>
> I guess what I am looking for is a statement about the best case scenario
> for an MUA to be able to display a message with some confidence given the
> current state of affair.
> For example, if there is a valid DKIM, an Authentication-Results header
> with dkim pass,and the header was provided by a trusted entity?
>

I would argue that the text that's there does give the best case scenario:
Absent a reputation system (which doesn't exist publicly, so the lowest
common denominator doesn't have this), it's dangerous for any component of
a mail system to trust a message just because some authentication system
passed.  The "value" of the attesting domain is what matters, and for the
most part you don't know what that value is.  Really large operators (e.g.,
Gmail) do have reputation systems, but your typical home open source
installation does not.


> 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.
>>
>>
> Fair enough; I think it is worth adding this sentence to make it clear.
>

Doesn't the last sentence of that paragraph already say exactly that?


>
>> 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.
>>
>>
> I guess it does hurt to remind implementer to pay attention to this issue,
> but I think it might be useful to state that there is nothing special about
> this header to avoid possible question like this in the future.
>

Adjusted the text accordingly.

-MSK