Re: [secdir] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sun, 04 November 2018 21:59 UTC
Return-Path: <rifaat.ietf@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 D985A128CB7; Sun, 4 Nov 2018 13:59:14 -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 QflhxqCHAnWi; Sun, 4 Nov 2018 13:59:12 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 DD66E12872C; Sun, 4 Nov 2018 13:59:11 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id t81-v6so5111634iod.10; Sun, 04 Nov 2018 13:59:11 -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=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=KDz1euOk8M0blDuE8gOgfrsuBxLPazMim59EUkkyYIHM59xWBplHjHu6n60FDQmfHp cvH8JEQJOlJL1jX6KGt1k1XyyGwoBGLYMu7T8a9W89XvlqgQ/zgs9F/ZWjViNxpTBlIA 6cZ6gYsSaNwRYquZsXtHlZGqlmHnL6DKZCqSqAdIVx0at9AQ5WIwnmP3nwLdoGAXqk1w GBmtAt7fv7wd9N8xKLXG27nVXqZ8nrlgxFmBLNT9+lnavNzL0UY6Im+2cTnW7cbGuEkU WfqQD6ablT9zgaE3im/qg/Mzrv/Y+iRmceAwzDzl7bmfNoYyoMqaRsJ0K3rHlLZG5AH0 ooQQ==
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=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=swrizmZtrj5hbAWRRne08HLp3TC5ETHD8ARwcpEx0rHkgnVhXtjmrfuzr3l2s9qgrS bxyYQBbtPUjY6OgOqFr5roJ6Zub1+kFS947UzqMfvL0bHVt2I2sGDXeEiLZchDzfNZKX HiVTQw7DnTGp1mmys+iHZ5+PikFj/AkT+rwRo7ijjjvXGjjDwVrv2Dicj/bcDBLeRUiz sGHWDg6IfAz8hNoVW3AlTSljhJJZuKn1PVeLhBtk/GGJHKllzCgCt/5E6DrVHQ7wGDgg /Mg03bF7LBSd5EWWytZdf54rqnO/gIGSnf1qr/6nUBwcV8WgWA2fOzrT7QuFpPXWdJAK ilQg==
X-Gm-Message-State: AGRZ1gLTkzlu3eRIkGfvuknpxCPUqa/opDpwAgIBmswBCrHav0oMFIuw 51yMNWxBlXQqichxWNcuxeGLtrWf11n95raFYYA=
X-Google-Smtp-Source: AJdET5fLp9HD5ATnPratuMl/Ee9W1PC4QWfQhfm9jY0myZ1d785jnqo1LU38FWfLIGNte9q/H8+uDoeA/JcUvsghhfg=
X-Received: by 2002:a6b:105:: with SMTP id 5-v6mr16961739iob.0.1541368751163; Sun, 04 Nov 2018 13:59:11 -0800 (PST)
MIME-Version: 1.0
References: <154100859354.5360.795312478907721541@ietfa.amsl.com> <CAL0qLwYoPy5FNx4rEW4NOKPHyPjfmW6OCYANnkeFUjjuvZQHrg@mail.gmail.com>
In-Reply-To: <CAL0qLwYoPy5FNx4rEW4NOKPHyPjfmW6OCYANnkeFUjjuvZQHrg@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Sun, 04 Nov 2018 16:59:01 -0500
Message-ID: <CAGL6ep+sX8sWf=G20gXMmKHAPua82gT+mwBq9cLSr46rC9tApg@mail.gmail.com>
To: superuser@gmail.com
Cc: secdir@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-rfc7601bis.all@ietf.org, IETF-Discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e18fdb0579dde0ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MN8dyUnZIslew-OSxvL52viYZEc>
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: Sun, 04 Nov 2018 21:59:15 -0000
On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <superuser@gmail.com> wrote: > On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > wrote: > >> 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 > appendix. > > 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 "example.com" should be interpreted such that I > trust that message more (or less). > > The two paragraphs you're talking about solve different problems. > I thought the DKIM signature is part of this header, but I now understand that it is a separate header. > > >> 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? > 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. > 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. Regards, Rifaat > -MSK >
- [secdir] Secdir last call review of draft-ietf-dm… Rifaat Shekh-Yusef
- Re: [secdir] Secdir last call review of draft-iet… Murray S. Kucherawy
- Re: [secdir] Secdir last call review of draft-iet… Rifaat Shekh-Yusef
- Re: [secdir] Secdir last call review of draft-iet… Murray S. Kucherawy