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

[Rifaat Shekh-Yusef <[e-mail]>]

On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <[e-mail]>
> 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
>