Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Nov 21, 2018 at 5:58 AM Benjamin Kaduk <[e-mail]> wrote:

>
> For example, in Section 1:
>
>    There exist registries for tokens used within this header field that
>    refer to the specifications listed above.  Section 6 describes the
>    registries and their contents and specifies the process by which
>
> I don't think all of this is still present anymore.  (If we were talking
> about registration policies, for example, we'd need an 8126 reference to
> replace the 5226 reference that was removed.)
>

There appears to be obvious consensus for restoring all of the text so that
this document is a complete description of Authentication-Results.
Hopefully the update I'm planning to post takes care of all of this.

[We should double-check that everything that now allows EAI-formatted
> stuff is updated to also refer to this document from the IANA registry.
> On first glance this might include vbr.mv and vbr.md, but probably much
> more.]
>

The pending update should take care of this as well.

Don't we need to mention the updates (or obsoletes) relationship w.r.t.
> 7601 in the Abstract and Introduction?
>

Since I started doing IETF work, it seems like there's never been
consistent guidance on this.  Some ADs ask for it, others find it redundant
to what's in the header of the first page and have asked me to remove it in
prior work.  I'll add it here and hopefully nobody pushes back.

Section 4.1 has:
>
>    MUAs and downstream filters MUST ignore any result reported using a
>    "result" not specified in the IANA "Result Code" registry or a
>    "ptype" not listed in the "Email Authentication Property Types"
>    registry for such values as defined in Section 6.  [...]
>
> This would seem to be an internal inconsistency, in that it seems to
> preclude any sort of experimental usage as described in Sections 2.7.x.
>

Fixed next version.

In Section 2.3:
>
>    Combinations of ptypes and properties are registered and described in
>    the "Email Authentication Methods" registry, coupled with the
>    authentication methods with which they are used.  This is further
>    described in Section 6.
>
> The relevant subsection of section 6 is a pretty empty stub now.
>

Fixed next version.

----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks you for updating in response to the secdir review!
>
> Are we now intending to restrict ourselvesto domain-based authentication
> schemes, having removed the disclaimer present in 7601 about the intent
> of the document?
>

No; this document talks about SMTP AUTH and reverse DNS authentication,
neither of which necessarily tie directly to domain names for domains in
the message.

Which disclaimer are you referring to?


> Section 1.1
>
>    In particular, the mere presence of this header field does not mean
>    its contents are valid.  Rather, the header field is reporting
>    assertions made by one or more authentication schemes applied
>    somewhere upstream.  For an MUA or downstream filter to treat the
>    assertions as actually valid, there must be an assessment of the
>    trust relationship among such agents, the validating MTA, and the
>    mechanism for conveying the information
>
> If this document is reporting assertions made upstream, we should say
> what kind of integrity and authenticity guarantees we do or do not
> provide for the reported information.  (That is, "this header is
> transmitted in cleartext and could be modified by any agent along the
> delivery path", modulo the speculation we have later about potential
> ways to improve on that situation.)  Section 1.6 goes a bit farther in
> this vein; maybe a forward reference is in order?
>

Eric made a suggestion about mentioning that the paths between components
that either generate or consume this header field must also be trusted, and
I've added that already.  Is that satisfactory?

Section 1.4
>
> Isn't there a requirement to drop this header on the boundary, if there
> are any internal consumers?  This is not a global requiremnet on
> existing servers, of course, but a deployment consideration that may
> affect existing servers.  The end of section 7.1 seems to cover this
> situation pretty well, as well.
>

This section is talking about changes to other protocols (there are none)
and required changes to message handling logic (i.e., you don't have to
start rejecting mail just because "dkim=fail" or something).

Section 1.5.1
>
> Please consider using the RFC 8174 version of the BCP 14 boilerplate.
>

Done in the new version.

Section 1.5.4
>
>    o  An "intermediate MTA" is any MTA that is not a delivery MTA and is
>       also not the first MTA to handle the message.
>
> Is this intended to be global or within an ADMD?
>

It's global.

Section 2.2
>
> I guess wouldn't be a whole lot of value in subtyping Keyword to have
> one symbol per registry, though the thought did occur to me while
> reading.
>

I agree, not really.

Section 2.3
>
>    body:  Information that was extracted from the body of the message.
> [...]
>       interest.  The "property" is an indication of where within the
>       message body the extracted content was found, and can indicate an
>       offset, identify a MIME part, etc.
>
> I'm not seeing where it's specified how the "property" gives an offset.
> I see other descriptions below about specific header fields and SMTP
> verbs and such, though.


That's text from the 2009 version of this work.  Those were speculative at
the time and haven't yet materialized, at least not in standardized use.


> (Do we need to make it more clear that the
> "property" is defined within the context of the method?)
>

That doesn't appear to have been necessary in the ~10 years since the first
version.

   The results for Sender ID are listed and described in Section 4.2 of
>    [SENDERID], but for the purposes of this specification, the SPF
>    definitions enumerated above are used instead.  Also, [SENDERID]
>    specifies result codes that use mixed case, but they are typically
>    used all lowercase in this context.
>
> We use much stronger statements about lowercasing than "typically",
> elsewhere in this doc.  Is this time different?
>

Removed.

Section 2.7.6
>
>    Experimental method identifiers MUST only be used within ADMDs that
>    have explicitly consented to use them.  These method identifiers and
>    the parameters associated with them are not documented in RFCs.
>    Therefore, they are subject to change at any time and not suitable
>    for production use.  [...]
>
> This part seems to value RFC status too highly -- earlier in the section
> we only say that they should "preferably" be published in an RFC.
>

I'll just make it "formally".

Section 2.7.7
>
> Do we want to say that temporary registrations are available for
> wide-scale or long-running experiments?
>

It's never come up before.  Since the registry includes the ability to mark
something "deprecated", one could do the registration and then deprecate it
if the experiment fails.  Or we could allow a third status of
"experimental".  But since there's never been such demand in the ten years
since the original version, I'd just as soon leave it until someone wants
to do it.

Section 3
>
>    of the validity of the connection's identity using DNS.  It is
>    incumbent upon an agent making use of the reported "iprev" result to
>    understand what exactly that particular verifier is attempting to
>    report.
>
> Does that in practice constrain "iprev" usage to within a single ADMD?
>

I would imagine so.

Section 4.1
>
>    MUAs SHOULD ignore instances of this header field discovered within
>    message/rfc822 MIME attachments.
>
> When would I want to not ignore it?
>

The discretion is left for operators that know what they're doing.  You
have to understand, for example, that you're going to be applying the
results of authentication checks done in the possibly very distant past.  I
can add a sentence or two to that effect.

Section 5
>
> I guess there's not really any special behavior to worry about when a
> message's path causes it to have two or more disjoint path segments in
> its delivery path that go through a given ADMD.  (That is, delete on
> entry is still the right thing to do.)  The last paragraph of Section
> 1.2 covers a related case, but I am thinking of something like a message
> that gets delivered to an expander and some of the recipients' delivery
> path would then return through a previously visited domain.
>
>                                                 For example, an MTA for
>    example.com receiving a message MUST delete or otherwise obscure any
>    instance of this header field bearing an authentication service
>    identifier indicating that the header field was added within
>    example.com prior to adding its own header fields.  [...]
>
> Do we want to say anything about the authserv-id here?
>

That's the "authentication service identifier".

Section 6.4
>
> I think we need to update the registry to also refer to this document.
>

It's in the pending update.

Appendix C
>
>    2.  Border MTAs are more likely to have direct access to external
>        sources of authentication or reputation information since modern
>        MUAs are more likely to be heavily firewalled.  [...]
>
> It's unclear that this statement about "modern MUAs" is still true,
> given the "zero trust" movement and such.
>

It's certainly still true in my work environment, but perhaps less so for
mobile devices.  I'll tweak the text accordingly.

-MSK