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

[Benjamin Kaduk <[e-mail]>]

On Sat, Jan 05, 2019 at 09:07:24PM -0800, Murray S. Kucherawy wrote:
> 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.

It seems pretty likely, yes.  I'll keep an eye out for the next rev and
clear my discuss accordingly.

> [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?
> 

I was thinking about "[t]his specification is not intended to be restricted
to domain-based authentication schemes, [...]".  I don't think we should
make any change to the document text (but if the answer was "yes", I might
have suggested something).

> 
> > 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?

I think that covers my concern, yes.

> 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).

It talks about required changes to message handling logic on existing
servers, and I am claiming that there is one such, in certain cases.  In
particular, when the new deployments that use this header are in the
interior of a network, the boundary servers of that network must drop
instances of this header that claim to represent that network from incoming
traffic, to ensure that the internal consumers only receive accurate data.
This is hardly a universal case, but may be worth mentioning explicitly.

> 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.

Okay, thanks.

> 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.

Are you proposing to leave the text unchanged regardless?

> 
> > (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.

A pretty solid argument :)

>    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.

Fair enough.  (IIUC, temporary registrations are globally available for
~all IANA registries, as a function of BCP 37 (e.g., RFC 2780 section 2),
so my suggestion was just to make this more widely advertised rather than
changing registration policy.)

> 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.

This is just the COMMENT section, so do what you will, but I would consider
mentioning this property of "iprev" more explicitly.

> 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.

Thanks!

> 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".

Whoops, sorry for missing that.

> 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.

Thanks!

-Benjamin