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

"Brotman, Alexander" <> Tue, 27 March 2018 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7568A127871; Mon, 26 Mar 2018 17:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZVr_9PgWqA0V; Mon, 26 Mar 2018 17:29:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B5CC126BF7; Mon, 26 Mar 2018 17:29:46 -0700 (PDT)
X-AuditID: 60721c4c-c0e6a7000000248e-b0-5ab99079ec7d
Received: from ( []) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 04.13.09358.97099BA5; Mon, 26 Mar 2018 20:29:45 -0400 (EDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Mon, 26 Mar 2018 20:28:56 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 26 Mar 2018 18:28:55 -0600
Received: from ([fe80::3aea:a7ff:fe36:8380]) by ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1365.000; Mon, 26 Mar 2018 18:28:55 -0600
From: "Brotman, Alexander" <>
To: Phillip Hallam-Baker <>, Alexey Melnikov <>
CC: "" <>, "" <>, IETF Discussion Mailing List <>, "" <>
Thread-Topic: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
Thread-Index: AQHTtxUkfu2V6vvAdU6QiQx2eVCljKPc2CmAgAAOj4CABm5KIA==
Date: Tue, 27 Mar 2018 00:28:55 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_81b2c2944a9143baafb4dc71af3788c8COPDCEX19cablecomcastco_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUOxpoVs5YWeUwbbnwhYzVhdZLJpyn8Xi 6vLjTBbPNs5nsfiw8CGLxamjzYwObB47Z91l91iy5CeTx6lmwwDmKC6blNSczLLUIn27BK6M bzdPshT05FR8PbSBrYFxSmYXIyeHhICJxLxd19m6GLk4hAR2MElMetPIDuE0M0n0NK9khXAO MUq8O7odquwko8TPyxOYQPrZBKwk3v5vZwaxRQSiJE407WICKWIWOMso0XvwNiNIQljAW+LU mWMsEEU+Eu2zF0A1OEkcWfUWyObgYBFQlfhxIBwkzCvgJbH9wSKozasYJVbeWcgOkuAUCJTY 1dQKZjMKiEl8P7UG7AhmAXGJW0/mM0E8JCCxZM95ZghbVOLl43+sELaBxNal+1ggbAWJ9/9O sUH05ku0/jjJBrFYUOLkzCdgNUICWhJ7b+yC6hWXOHxkB+sERslZSNbNQtI+C0n7LKB3mAU0 Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRh5LMz1DQxM9Iws9c7NNjKCIL5Lx2cH4aZrH IUYBDkYlHl7Opp1RQqyJZcWVucDY4GBWEuHlm78jSog3JbGyKrUoP76oNCe1+BCjNAeLkjjv zBCgaoH0xJLU7NTUgtQimCwTB6dUAyODbLboAXnzSpcA9ZXSTauUYrYllezYGDbXVOuQ7ve/ +nXt5x/zOptukOsRspoZ5NF+zSH4a6infoT5i/LPHO/ZakUmrn19QfPs4y4Vldy0D5dK2Z15 /DWemjX2SJ29nBy7UnxCmMn3v/enXlGYsvm999zbmuvrhF4qfbvw3lHZ+OECl5XWkkosxRmJ hlrMRcWJAA3HqSf0AgAA
Archived-At: <>
Subject: Re: [secdir] [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Mar 2018 00:29:48 -0000

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 "", 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 “” or “”?

Alex Brotman
Sr. Engineer, Anti-Abuse

From: Uta [] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, March 22, 2018 12:09 PM
To: Alexey Melnikov <>;
Cc:;; IETF Discussion Mailing List <>;;
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 <<>> 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,