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