Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

["Brotman, Alexander" <[e-mail]>]

I may have missed the consensus on this.  I don’t believe the final DNS entry is hugely important as it pertains to TLSRPT on its own, as long as it extends from the target domain.  So, today we have "_smtp-tlsrpt.example.com", but it seems like to get more in line with a proper IANA registration, we should alter this slightly.  Is there any reason to not go forward with “_smtp._tls.example.com” or “_smtp._tlsrpt.example.com”?

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: Uta [mailto:[e-mail]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, March 22, 2018 12:09 PM
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]; [e-mail]; IETF Discussion Mailing List <[e-mail]>; [e-mail]
Subject: Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

I concur, I had come to essentially the same conclusion after discussions with IANA. The registry we were looking for was the one Dave had proposed that has not yet been created.

I can sync with Dave.

It might well be that what we want is a sub registry of the form _smtp._rpt. That way the reporting info for any protocol can be discovered with no need to obtain a per service registration.

On Thu, Mar 22, 2018 at 3:17 PM, Alexey Melnikov <[e-mail]<mailto:[e-mail]>> wrote:
Hi Phillip,
To followup on the IANA issue from your SecDir review:

On 08/03/2018 19:39, Phillip Hallam-Baker wrote:
>
> Specific issues
>
> The DNS prefix _smtp-tlsrpt is defined. This is not mentioned in the IANA
> considerations. It is a code point being defined in a protocol that is outside
> the scope of UTA and therefore MUST have an IANA assignment and is a DNS code
> point which is shared space and therefore MUST have an assignment.
>
> If no IANA registry exists, one should be created.

After looking at this in more details, I think a new registration in the
registry being created by draft-ietf-dnsop-attrleaf is exactly what you
are asking for. I think registering _smtp-tlsrpt there should be
straightforward. However I don't think this document should be delayed
until after draft-ietf-dnsop-attrleaf is done. So if
draft-ietf-dnsop-attrleaf is taking time, the proposed registration can
be moved to draft-ietf-dnsop-attrleaf itself.

> In general, the approach should be consistent with the following:
>
> [RFC6763] S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC 6763
> DOI 10.17487/RFC6763 February 2013
>
> It might well be appropriate to create a separate IANA prefix registry
> 'report'. That is probably easier since this prefix does not fit well with the
> existing ones.
>
> _smtp-tlsrpt._report

I think this is covered by draft-ietf-dnsop-attrleaf.

Best Regards,
Alexey



--
Website: http://hallambaker.com/