Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Nov 2019 22:30:05 -0800

On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely <[email-masked]> wrote:

> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
> >
> >> If the definition of ptype smtp were "a parameter of the SMTP session
> used
> >> to relay the message" it would be perfect.  I'd propose that
> policy.iprev
> >> be deprecated and smtp.remote-ip used instead>>
> >
> > Given that RFC8601 was published just last month, it'll probably be a
> while
> > before this happens.
>
> Wouldn't an accepted erratum be enough to change the wording in the IANA
> page?
>

That's not what the RFC Editor erratum system is for.  The document
reflects what the WG intended to publish at the time, so this isn't an
erratum, it's a new change to the specification.

About the new ptype, a reviewer suggested to also use it to report whether
> the
> query supported DNSSEC.  No DNSWL that I know supports it.  However, I know
> some DKIM filters report that feature either as a comment or as a reason
> in the
> dkim= methodspec.  Using the new ptype might make that clearer.  Consider:
>
>     Authentication-Results: example.com;
>       dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv
>

Are there any MTAs that would take a different action based on this
information?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Nov 2019 23:48:01 -0800

> erratum, it's a new change to the specification.

Just to be clear: The policy for changes to that registry is "Expert
Review", but since the action that put it there was a document with IETF
consensus, I'm pretty hesitant about just approving this change based on a
formal request.  I'd rather at least see some consensus discussion about
it, or even better, a revision/update to RFC8601.

-MSK, this time as DE

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Nov 2019 09:16:24 +0100

On Mon 11/Nov/2019 07:30:05 +0100 Murray S. Kucherawy wrote:
>> About the new ptype, a reviewer suggested to also use it to report
>> whether the query supported DNSSEC.  No DNSWL that I know supports it.
>> However, I know some DKIM filters report that feature either as a comment
>> or as a reason in the dkim= methodspec.  Using the new ptype might make
>> that clearer.  Consider:>>

Nobody cares about DNSSEC, until they fall victim to DNS hijacking attacks.

If the property is there, it may be easier to retrofit a fix in that case.

Best
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 11 Nov 2019 09:21:29 +0000

> Are there any MTAs that would take a different action based on this

For Exim it would be a fairly simple bit of additional ACL, in
the config file.
-- 
Cheers,
  Jeremy

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Nov 2019 10:23:05 +0100

On Mon 11/Nov/2019 08:48:01 +0100 Murray S. Kucherawy wrote:
> On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy wrote:
>> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:

>>>>> On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote:
>>>>> 
>>>>>> Note that  RFC8617 section 10.2 (
>>>>>> https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
>>>>>> smtp.remote-ip method item.

>>>>> If the definition of ptype smtp were "a parameter of the SMTP
>>>>> session used to relay the message" it would be perfect.  I'd propose
>>>>> that policy.iprev be deprecated and smtp.remote-ip used instead
>>>> while before this happens.

>> erratum, it's a new change to the specification.

Yes, as DE you could change it without an erratum.  However, an erratum would
serve as a justification to any reader who followed the definitions and noticed
a mismatch.

The ptype table was introduced by rfc7401, Section 3:

       +--------+-------------+----------------------------------------+
       | smtp   | RFC 7001    | The property being reported is a       |
       |        | Section 2.2 | parameter to an SMTP command used to   |
       |        |             | relay the message.                     |
       +--------+-------------+----------------------------------------+

Rfc7601 and rfc8601, both in Section 6.4 claim to be a complete restatement of
the definition and rules for this registry, and direct IANA to update this
registry to show their Section 2.3.  However, IANA still has the above definition.

> it, or even better, a revision/update to RFC8601.

I think this group would make a better use of its time by discussing rfc7489bis
than rfc8601bis.  If group consensus can be enough for the time being, an
erratum can also serve as a reminder.  So I ask for it:

Does the WG agree to an erratum as follows:

TYPE: technical

SECTION: 2.3

ORIGINAL TEXT:

   smtp:  Indicates information that was extracted from an SMTP command
      that was used to relay the message.  The "property" indicates
      which SMTP command included the extracted content as a parameter.

CORRECTED TEXT:

   smtp:  Indicates information that was extracted from a parameter of
      the SMTP session that was used to relay the message.  The
      "property" indicates which parameter included the extracted content.

NOTES

   This change makes the "smtp" type consistent with the definition of
   smtp.remote-ip given in rfc8617 Section 10.2.

?

TIA for answers
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:50:30 -0800

>    smtp.remote-ip given in rfc8617 Section 10.2.

This seems like a bit of a nit, but also seems to be an accurate
wordsmithing of the definition.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2019 10:54:09 -0500

>it, or even better, a revision/update to RFC8601.

Hey, wait, Expert Review is supposed to be considerably looser than RFC Required.

Since there's no danger of running out of token names, I'd encourage
you to accept new ptypes if they have a clear spec and a plausible use
case.  In this instance, I think the description in the I-D is OK, but
for the use case I would like some evidence that someone, somewhere is
implementing it and doing something with the result.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Nov 2019 20:07:50 +0000

On November 11, 2019 3:54:09 PM UTC, John Levine <[email-masked]> wrote:
>In article
><CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=[email-masked]>
>you write:

I've had feature requests to include both s= Service Type (due to tlsrpt) and t= Flags (particularly t=y (testing)).  Since they are attributes of the DNS record and not the signature, I think the proposed dns ptype would be appropriate.

I plan to implement it in dkimpy and expose the values in dkimpy-milter.  I'd like some indication that it'll move forward first.

I think we can adequately define the ptype in the registry.  I don't think we need to have a spec.  For the rest of Ale's draft, I'm not convinced a registry entry is enough to document the proposed usage. (Speaking as alternate DE - msk is the primary though, so this is not an attempt to override him).

msk: What do you think about the idea of approving the new ptype now (so I can file requests for the above, well defined, DKIM result reporting enhancements)?

Scott K