So, we'd need to create a new Service Type (I see only * and email currently), correct? Could we alternately use the "n=" field and require that the note be set to "tlsrpt"? If we do add this, and the receiving party is unable to find the appropriate s= or n= for the key, should they then discard the report?
-- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Uta [mailto:[email protected]] On Behalf Of Jim Fenton Sent: Wednesday, March 14, 2018 4:13 PM To: [email protected] Subject: Re: [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17 Requiring that the selector have a particular name or name prefix associates semantics with selector names, of which there is none. It also requires the management (e.g., rotation) of more keys per domain. There is a better way to do this. The s= tag on the key record (service type) can be used to distinguish keys that are only supposed to sign normal mail from those that may sign TLS reports (or those that may be used for either). The default is "*", that the key can be used for any service. For domains that are concerned that users may sign spoofed TLSRPT messages, they can specify s=email for keys intended for normal use and s=tlsrpt (I'd propose) for those that may sign TLSRPT messages. This way TLSRPT only complicates the key management when the is potential for abuse. Then require that it only accept TLSRPT messages when signed with a key permiting the appropriate service See RFC 6376 section 3.6.1, description of s= tag. -Jim On 3/14/18 4:21 AM, Brotman, Alexander wrote: > 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:[email protected]] > Sent: Thursday, March 08, 2018 6:47 PM > To: Viktor Dukhovni <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > 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 <[email protected]> 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. >> > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
