I don't see any reason a specific DKIM selector wouldn't be possible. We'll see if we can get some language added to address the clarifications you've requested. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] Sent: Thursday, March 08, 2018 6:47 PM To: Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> Cc: gen-art@xxxxxxxx; uta@xxxxxxxx; draft-ietf-uta-smtp-tlsrpt.all@xxxxxxxx; ietf@xxxxxxxx Subject: Re: [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17 A reasonable perspective. Could that be added to the document? Yours, Joel On 3/8/18 6:33 PM, Viktor Dukhovni wrote: > > >> On Mar 8, 2018, at 5:28 PM, Joel Halpern <jmh@xxxxxxxxxxxxxxx> wrote: >> >> It is surprising in Section 3 Bullet 4 that reporting via email requires >> that the report submitted use DKIM. Particularly while ignoring any >> security errors in communicating with the recipient domain. > > Actually, this is not surprising. The main security risk here is > report spam, that will drown the true signal in noise, making it > impossible to notice real validation failures or operate the service. > > Therefore, the report origin domain must be authenticated via DKIM. > I'd be tempted to go further and require a particular "selector" > prefix that is specifically chosen for "tlsrpt", so that with domains > such as "gmail", where anyone can get an email account, just being a > user on the sending system is not enough to be able to forge a DKIM authenticated report. > But that would create significant complications for the sender to make > it so, and so is probably not needed. > > In summary, when sending reports the party that needs to be > authenticated is the sender domain, while the receiving domain is > presumed operationally compromised, and so should be exempt from any authentication requirements. >
