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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 5 Jan 2019 21:07:24 -0800

On Wed, Nov 21, 2018 at 5:58 AM Benjamin Kaduk <[email-masked]> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 6 Jan 2019 11:27:30 -0600

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

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

> I've added that already.  Is that satisfactory?

I think that covers my concern, yes.

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

> > Is this intended to be global or within an ADMD?

Okay, thanks.

> the time and haven't yet materialized, at least not in standardized use.

Are you proposing to leave the text unchanged regardless?

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

A pretty solid argument :)

> since the original version, I'd just as soon leave it until someone wants

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

> > Does that in practice constrain "iprev" usage to within a single ADMD?

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

> can add a sentence or two to that effect.

Thanks!

> That's the "authentication service identifier".

Whoops, sorry for missing that.

> mobile devices.  I'll tweak the text accordingly.

Thanks!

-Benjamin

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jan 2019 02:25:45 -0500

> Are you proposing to leave the text unchanged regardless?

I know the use case exists, because I wrote that text when I worked for a
company that was likely to make use of it, but it appears that hasn't
happened in the deployed universe.  So now we have a registry entry for the
"body" ptype which isn't deprecated, but possibly no live uses of it.  The
working group didn't discuss taking any action to either "fix" or bolster
this, as its focus was elsewhere (specifically the changes needed to
support the DMARC/ARC work).

I'm inclined to leave it as-is, possibly with a remark capturing what I
just said here.  If no uses of it appear before someone decides to revise
this again, we can formally deprecate it.

> mentioning this property of "iprev" more explicitly.

Actually, on second thought, it doesn't: ADMD #1 could attach an "iprev"
result that ADMD #2 could decide it trusts.  That is, sort of, the ARC
model -- you decide whose external results you're going to believe.

About to post the new version.

-MSK

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Jan 2019 08:48:18 -0600

> this again, we can formally deprecate it.

Okay.

> model -- you decide whose external results you're going to believe.

Part of that seems to be having a side agreement between ADMD #1 and ADMD
#2 about the semantics in use in order for the trust to be meaningful.  But
I guess we don't need an IETF standard for that to be possible.

> About to post the new version.

Thanks.

-Benjamin

---

From: "John Levine" <[email-masked]>
Date: 21 Jan 2019 22:14:50 -0500

In article <CAL0qLwbmcEVgVcJTBU26gmVGaWV4Gy0fYArY80ZcDYf=[email-masked]> you write:
>"body" ptype which isn't deprecated, but possibly no live uses of it. ...

I'd leave it there, at least so nobody inadvertently reuses the ptype name.

Apropos the comment about VBR, as far as I can tell nobody uses it so
I'm not inclined to spend much effort on it, but the text in -04 is
fine.  If someone wants to put U-labels in their VBR headers, it's OK
with me.

R's,
JOhn