Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

From: Alessandro Vesely <[email-masked]>
Date: Wed, 1 Aug 2018 14:16:57 +0200

On Tue 31/Jul/2018 15:10:21 +0200 Murray S. Kucherawy wrote:
> 
>>> Do you have a suggestion for alternative text?
>>
>> Say:
>>
>>     In that case, if the producer intent is not to harm or mislead, the trust
>>     in this field's content would be proportional to the estimated quality of
>>     the producer's software.  Consumer's wisdom is key.
>
> How is a receiver to know anything about the estimated quality of the 
> producer's software?

Being proportional works both ways.  You can estimate the quality from the
accuracy of the content, then you can trust the field content (of a different
method or message) based on what you learned about that operator.

>>>> *special-smtp-verb*
>>>> This rule is redundant and, if we're after readability, can be 
>>>> striked.  In fact, both terms it produces fall under the "Keyword"
>>>> rule.  In addition, IANA reports smtp.rcptto as defined by rfc7293, so
>>>> it can be omitted here.>>>
>>> It's not redundant.  MAILFROM and RCPTTO are not SMTP verbs.
>>
>> Right, but their formation is well described in the relevant paragraphs, 
>> which I quote:>>
>>    The list of commands eligible for use with the "smtp" ptype can be
>>    found in Section 4.1 of [SMTP].
>>
>>    [...omitted paragraph here...]
>>
>>    Where an SMTP command name is being reported as a "property", the
>>    agent generating the header field represents that command by
>>    converting it to lowercase and dropping any spaces (e.g., "MAIL FROM"
>>    becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).
>>
>> Please note that a dumb reader might fail to derive that the latter 
>> paragraph is constrained by the former.  (Perhaps reordering and/or
>> merging might help.)>
> I'm not clear on how ordering helps here.  You need the two together 
> regardless of order.

I meant something like so:

   The list of commands eligible for use with the "smtp" ptype can be
   found in Section 4.1 of [SMTP].  To report an SMTP command name as a
   "property", the agent generating the header field represents that
   command by converting it to lowercase and dropping any spaces (e.g.,
   "MAIL FROM" becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).

> I'm also not clear on what problem you're trying to solve.

No problem.  That reorder and merge is just a marginal hint to improve readability.

> Keep in mind that this is now something like the fourth version of this
> document, and this has not been identified as a deficiency in any prior
> version.  Is this actually broken?
No, it is not broken, AFAICS.  Rather, it's better than previous versions,
where the "policy" ptype was overloaded beyond clarity, from covering
unregistered properties, to overriding methods' results, to catchall for any
property not extracted directly from the message session.

>> This message is an example.  Unless removed, it bears a header field like:
>>
>>     Authentication-Results: tana.it; auth=pass (details omitted)
>>
>> It means I was SMTP-authenticated when I posted the message (otherwise it 
>> wouldn't have been DKIM-signed.)  However, for obvious reasons, I don't 
>> want to disclose the userid I authenticated with.
>
> I think that's operationally a poor choice.

Agreed.  However, my signing agent knows nothing about any AUTH= parameter to
the MAIL FROM command.  It just knows the (non-public) smtp.auth.  What A-R
field should it write?

> The whole point of the data that come after the pass/fail is to tell
> downstream agents what identifier(s) might be of interest to record or
> highlight to users.  If you managed to authenticate as the identity in the
> From: field, that's a lot more interesting than if you authenticated as
> something unrelated; the fact that the filter adding this left out that key
> piece of information almost makes it useless.
I beg to differ here.  If the authentication token is syntactically equal to
the [local-part of the] mailbox address, this can be considered as substantial
data leakage, given that the mailbox address is public.

IMHO, in a multi-host implementation where downstream agents need to acquire
smtp.auth, there should be a final agent to redact it before it crosses the
trust boundary.  For example:

    Authentication-Results: example.net; auth=pass
       smtp.auth=[email-masked]

Or, according to rfc6590 algorithm:

    Authentication-Results: example.net; auth=pass
       smtp.auth=rZ8cqXWGiKHzhz1MsFRGTysHia4=@example.net

Or just remove the header field entirely.  Which is better?  Also compare with
varying values of From::

    From: [email-masked]
    To: [email-masked]
    Authentication-Results: example.net; auth=pass
       smtp.auth=[email-masked]

>>>> *policy*
>>>> This ptype can now evolve from catchall to meaningful indicator:
>>>> OLD:
>>>>
>>>>    A "ptype" value of "policy" indicates a policy decision about the
>>>>    message not specific to a property of the message that could be
>>>>    extracted.  See Section 2.4 for details.
>>>>
>>>> NEW:
>>>>
>>>>    A "ptype" value of "policy" indicates a policy decision about the
>>>>    method.  Its presence in a "resinfo" indicates that the algorithmic result
>>>>    of the method might have been overridden because of an internal criterion.
>>>>    Both "property" and "pvalue" concur at hinting what the internal criterion
>>>>    was.  See Section 2.4 for details.
>>>>
>>>> The above interpretation is based on the example in Section 2.4, The 
>>>> "policy" ptype, which reads:
>>>>
>>>>       ... dkim=fail policy.dkim-rules=unsigned-subject ...
>>>
>>> I disagree, because I think the existing text still adequately captures
>>> this case; there's been a policy decision made that was unrelated to some
>>> value found in a header field or tag (i.e., it's not a straight "fail"),
>>> but rather some combination of things that violates something the verifying
>>> ADMD wants to enforce.
>>
>> Isn't that exactly the definition of policy?
>>
>>    policy:  The message was signed, but some aspect of the signature or
>>       signatures was not acceptable to the ADMD.
>
> Yes, so is there a need to restate all of that here?  That's all laid out 
> in Section 2.4.

Both dkim=fail and dkim=policy are valid ways to override the method's
algorithmic result.  To exemplify the preferred way is fine for me.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Aug 2018 04:03:01 -0700

To the rest of the WG: Is there consensus to make this change or the
others being proposed?

I feel like we're making a lot more edits here than the WG intended to
make.  It's fine if the WG wants to turn this into a larger editorial pass,
but I thought the updates here were tightly scoped before, namely just
enough to allow ARC to do what it needs.

I'm inclined to resist, absent consensus, any changes that are other than
(a) something ARC needs, or (b) something clearly incorrect.

> method or message) based on what you learned about that operator.

How is a receiver supposed to go about estimating the quality of something?

This is starting to feel a lot like either scope creep or philosophical
ruminating (or both).  Do we really want to get into things like that in
this document?

> No problem.  That reorder and merge is just a marginal hint to improve

I'd like to know what the WG thinks here as well.

> property not extracted directly from the message session.

It has always been deliberately ambiguous, since we obviously can't specify
all policy-based decision trees.  But the intent has always been to
identify situations where a method failed for a reason other than that
method's defined algorithms reporting a failure result.

> the MAIL FROM command.  It just knows the (non-public) smtp.auth.  What A-R

I would suggest not adding one at all.  What is a downstream agent to do
with a plain "auth=pass"?

> data leakage, given that the mailbox address is public.

How would a verifier determine syntactical equivalence?

>        smtp.auth=[email-masked]

This is almost certainly scope creep.  What do others think?

> algorithmic result.  To exemplify the preferred way is fine for me.

Ah, the example is wrong.  Will fix it.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2018 10:25:52 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

Not that I've seen.  I thought we agreed to make changes to support ARC, to
handle EAI, and to fix any actual errors.  Other than that, leave it alone.

R's,
John

>> > producer's software? ...

---

From: Seth Blank <[email-masked]>
Date: Fri, 3 Aug 2018 07:35:56 -0700

> handle EAI, and to fix any actual errors.  Other than that, leave it alone.

+1. ARC, EAI, and errors only.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Aug 2018 07:51:59 -0700

On 8/3/2018 7:35 AM, Seth Blank wrote:
> On Fri, Aug 3, 2018 at 7:25 AM, John Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

+2

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 3 Aug 2018 11:44:49 -0700

> +1. ARC, EAI, and errors only.

Ditto

---

From: Tim Draegen <[email-masked]>
Date: Fri, 3 Aug 2018 17:55:24 -0400

> On Aug 3, 2018, at 7:03 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> I feel like we're making a lot more edits here than the WG intended to make.  It's fine if the WG wants to turn this into a larger editorial pass, but I thought the updates here were tightly scoped before, namely just enough to allow ARC to do what it needs.

I supplied a list of editorial + bug fixes. IMO there's a fuzzy line between fixing errors, removing ambiguity, and de-torturing sentences for future readers.

I'm also a fan of using tight scoping to keep focus, but need to point out that this WG has relaxed scope in the past to take on far more challenging work. Given that no document is ever taken on purely for editorial fixes, I'm OK with correcting the confusing bits while the door is open.

-= Tim