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:jmh@joelhalpern.com] 
> Sent: Thursday, March 08, 2018 6:47 PM
> To: Viktor Dukhovni <ietf-dane@dukhovni.org>
> Cc: gen-art@ietf.org; uta@ietf.org; draft-ietf-uta-smtp-tlsrpt.all@ietf.org; ietf@ietf.org
> 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@joelhalpern.com> 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
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta