Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks

[Alessandro Vesely <[e-mail]>]

On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote:
> On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote:
>> On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote:
>>> On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely <[e-mail]> wrote:
>>>> On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
>>>>> As I would hope everyone in this discussion would be aware, the "as if" 
>>>>> rule applies to all IETF standards.  You can do whatever you want so 
>>>>> long as the result is the same as if you had done what the spec says.
>>>>
>>>> The "as if" rule also holds for the case that all domains are equal, the 
>>>> case that no policy record is found, and the case that all alignments 
>>>> are strict.  Shortcuts have been part of the draft at least since April, 
>>>> and their presence seems to be accepted by the WG.
>>>>
>>>> I don't understand why those shortcuts deserve being mentioned while the 
>>>> parent-child does not.
>>>>
>>> I think you're proposal is somewhat different than the existing shortcuts. 
>>> The existing items in the note are cases where the tree walk can be 
>>> skipped entirely.  Your suggested addition is about a shortcut within the 
>>> tree walk algorithm.  I think that makes it sufficiently different to 
>>> merit independent consideration.
>> 
>> They're all shortcuts.  In the case I presented there is only a query to 
>> _dmarc.signing.dept.example.com (NXDOMAIN).  In the second of the three 
>> ones there is a first tree walk that yields no record.  That sounds similar 
>> to me.
> 
> I agree that there is some similarity, but I think that they are distinct.  I 
> think someone needs to apply judgement on how far to go.  I'm comfortable with 
> where the draft authors have decided enough is enough, but I understand 
> opinions may differ.


Thanks.


>>>> In addition, presenting the shortcuts in the middle of the algorithm 
>>>> specification can alter its meaning.  See below.
>>> I disagree.  They're marked as part of a note, so are not part of the 
>>> specification.  This is a reasonably common thing to do in IETF RFCs.
>> The note is not fully indented.  It disrupts the text enough to make it 
>> necessary to add the paragraph that immediately follows it.  The added 
>> paragraph is way too generic than needed.
>>
>> In general, there is no reason to specify exceptions before rules.
> 
> I'm happy to accept the draft authors judgement on this, either way, both 
> regarding the location and the indenting.


I understand the (ed) mark that Todd and John added after their names 
is meant to hold the WG responsible for the text.  Feeling 
responsible, and having been caught by the wrong meaning of that 
paragraph, I want it to be amended.


> I do agree it might be better to make it more visually distinct, 
> but I think we have lots of time for polishing the document and 
> it's a detail that shouldn't block the question of if we're agreed 
> on the tree walk as our approach.

I'm not trying to take back the WG decision.  IIRC, the decision was 
made at the meeting.  There is no question on that.

The point is to express it clearly.


> Is the "added paragraph" you're referring to this:
> 
>>     To discover the Organizational Domain for a domain, perform the DNS
>>     Tree Walk described in Section 4.6 as needed for any of the domains
>>     in question.
> 
> If so, I disagree.  I think that the section on org domain determination needs 
> to point to 4.6 regardless of if the notes are where they are or elsewhere. 
> The text is changed slightly for the next revision in Git, but either way I 
> think it's needed.


Yes, that's the paragraph.  I agree a reference to the Tree walk is 
needed.  Indeed, the section starts with this sentence:

     For Organizational Domain discovery, it may be necessary to
     perform multiple DNS Tree Walks in order to determine if any two
     domains are in alignment.

So, the only added info of the questioned paragraph is "4.6".


>>>>> As I have repeatedly asked, if you think there are places where the 
>>>>> tree walk results are wrong, show us some examples.  Otherwise, please 
>>>>> stop.
>>>>
>>>> Here you are:
>>>>
>>>> I hope you agree that .com is a domain.  The spec says that in order to 
>>>> discover the Organizational Domain for a domain, I can perform the DNS 
>>>> Tree Walk as needed for any of the domains in question.  That way, the 
>>>> domain in question, .com, is the Organizational Domain of itself.  That 
>>>> is wrong because .com is a PSD.
>>>>
>>>> Oh, perhaps "in question" refers to the three cases mentioned in the 
>>>> Section's intro?  It doesn't say so, it says a tree walk "might start" 
>>>> there, without excluding other possibilities.  "In question" can 
>>>> legitimately be understood to refer to any domain at hand.
>>>>
>>>> Furthermore, the parenthesized reinforcement "if present and 
>>>> authenticated" in a domain in the first shortcut casts a shadow on the 
>>>> requirement that all identifiers except From: must be authenticated —if 
>>>> that requirement were clear, there'd be no need to reinforce it. This 
>>>> corroborates the wrong interpretation.
>>>>
>>> First, if .com had a DMARC record and .com sent mail, it could be both a 
>>> PSD for lower level domains and it's own organizational domain for 
>>> itself, so your conclusion is incorrect.  We have discussed this multiple 
>>> times.  I think we most recently used .gov.uk as a more realistic 
>>> example.
>> 
>> No, I'm not hypothesizing that .com had a record and passed the requirements 
>> stated (somewhat unclearly) right at the beginning of section 4.8.  I'm 
>> pointing out that the paragraph after the note relaxes those requirements. 
>> Indeed, it says that the algorithm is valid for any domain.
> 
> I fear that I'm understanding you less as a result of this email, not more.
> 
> In an email earlier today you said:
> 
>> Therefore, a sending (or signing) PSD operates as part of its org domain.
> 
> Your original premise in this section of the email seems to be the opposite of
> that, so I'm certain I don't know what you mean.


In the email you cite I'm talking about the algorithm, now that I 
finally got it.  In the paragraph above I'm talking about how the way 
the algorithm is currently written can be wrongly interpreted.


>>> I think we have been through this more than once and we should not do it 
>>> again.
>> 
>> Yes, we've been here before, but we didn't conclude:
>> https://mailarchive.ietf.org/arch/msg/dmarc/sxijuMsZuBlinO4x_SN5qhJ08nM/
> 
> OK.  Here's what you proposed:
> 
>>       For each Tree Walk that retrieved valid DMARC records starting
>>       from the RFC5322.From domain, the SPF-validated RFC5321.MailFrom
>>       domain, or a DKIM-validated d= domain, select the
>>       Organizational Domain by looping from the longest to the shortest:


Forget that.  I just unimaginatively followed the requirement you 
stated upthread.  I agree with John's comment that that requirement is 
already expressed at the beginning of the section.


>>> Second, your "Furthermore..." claim reads to me as because the text says 
>>> the identifier must be present and authenticated, it will make readers 
>>> likely to think that the opposite is true.  I think you should take a 
>>> step back and reconsider your suggestion as it doesn't seem at all 
>>> logical to me.
>> Why?  For example "Consider all American cars.  Note, if limiting to Ford 
>> and GM (which really are cars), then...".  Doesn't the parenthesized part 
>> instill the doubt that the whole set includes something which somehow is 
>> not really a car?
> 
> No.


We obviously speak different languages.


>>>> I'd specify the algorithm first and discuss shortcuts after.
>>>
>>> If they are correct, it doesn't matter where the note is and if they are 
>>> wrong, they should be fixed.
>> It is the paragraph after the note which is not correct.  It adds nothing. 
>> Its only purpose seems to be to re-introduce the framework, after the note. 
>> However, in doing so it relaxes the requirements.
> 
> No.  I don't think it does and I don't understand how you could possibly
> interpret it that way (see my answer above where you complained about the same
> paragraph).


If you're sure it's a rabbit, you cannot see the duck.
https://en.wikipedia.org/wiki/Rabbit%E2%80%93duck_illusion


>>>   I don't think they are wrong and we should move on.
>>
>> Perhaps you've been too much involved in authoring that text.  Please 
>> consider the hypothesis that you and John intuited something which does not 
>> actually correspond to what you wrote.
>>
>> I'm usually not classified as subnormal, have been programming since the 80s 
>> and running a mail server for 20 years.  Yet, I got it wrong, and you had 
>> to write several clarification messages before I could grasp the algorithm 
>> you mean.  I had misunderstood what the draft says.  After I finally got 
>> it, I identified the misleading paragraph which deceived me.  I'm asking 
>> that it be removed.
> 
> Here's what's currently in Git between the shortcuts and the numbered steps
> (it's in Markdown, vice final RFC text, but I think it's clear enough):
> 
>> To discover the Organizational Domain for a domain, perform the DNS Tree
>> Walk described in (#dns-tree-walk) as needed for any of the domains in
>> question.


What are the "domains in question"?


>> For each Tree Walk that retrieved valid DMARC records, select the
>> Organizational Domain from the domains for which valid DMARC records were
>> retrieved from the longest to the shortest:
> 
> If we change this to:
> 
>> To discover the Organizational Domain for these domains, perform the DNS
>> Tree Walk described in (#dns-tree-walk) as needed for the domains in
>> question.  For each Tree Walk that retrieved valid DMARC records, select the
>> Organizational Domain from the domains for which valid DMARC records were
>> retrieved from the longest to the shortest:
> 
> Does that resolve your concern?  I changed "for a domain" to "for these
> domains" to address your concern about relaxing requirements.  I think you're
> wrong and it makes absolutely no difference, but if you think it's better,
> believe it would do.  I do think the two sentences would better be in one
> paragraph as they are not really separate ideas.


How about moving the reference to the Tree Walk right to the first 
sentence at the beginning of the section, for example like so:


     For Organizational Domain discovery, in general it is necessary to
     perform two DNS Tree Walks (#dns-tree-walk)" in order to determine
     if any two domains are in alignment.  Noteworthy exceptions are
     described in (#shortcuts).  A DNS Tree Walk to discover an
     Organizational Domain can start only at one of the following
     locations:

     * The domain in the RFC5322.From header of the message.
     * The RFC5321.MailFrom domain if there is an SPF pass result for
       the message.
     * Any DKIM d= domain if there is a DKIM pass result for the
       message for that domain.

     For each Tree Walk that retrieved valid DMARC records, select the
     Organizational Domain from the domains for which valid DMARC
     records were retrieved from the longest to the shortest:

     1  ...


Best
Ale
--