IETF Logo Mail Archive

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

"Brotman, Alexander" <Alexander_Brotman@comcast.com> Mon, 12 March 2018 22:36 UTC

Return-Path: <Alexander_Brotman@comcast.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E37127010; Mon, 12 Mar 2018 15:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RMH_u7ECoFc; Mon, 12 Mar 2018 15:36:06 -0700 (PDT)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC2C12422F; Mon, 12 Mar 2018 15:36:06 -0700 (PDT)
X-AuditID: 60721c4c-14b539e00000248e-45-5aa700d44d40
Received: from VAADCEX09.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id BA.5F.09358.4D007AA5; Mon, 12 Mar 2018 18:36:04 -0400 (EDT)
Received: from COPDCEX23.cable.comcast.com (147.191.124.154) by VAADCEX09.cable.comcast.com (147.191.102.76) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 12 Mar 2018 18:34:59 -0400
Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX23.cable.comcast.com (147.191.124.154) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 12 Mar 2018 16:34:58 -0600
Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1365.000; Mon, 12 Mar 2018 16:34:58 -0600
From: "Brotman, Alexander" <Alexander_Brotman@comcast.com>
To: Phillip Hallam-Baker <hallam@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "uta@ietf.org" <uta@ietf.org>, "draft-ietf-uta-smtp-tlsrpt.all@ietf.org" <draft-ietf-uta-smtp-tlsrpt.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
Thread-Index: AQHTtxUkfu2V6vvAdU6QiQx2eVCljKPNNT0A
Date: Mon, 12 Mar 2018 22:34:57 +0000
Message-ID: <e114c12f91fb442399cc37176fc685e0@COPDCEX19.cable.comcast.com>
References: <152053794569.13938.10396254284390037265@ietfa.amsl.com>
In-Reply-To: <152053794569.13938.10396254284390037265@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsWSUOxpoXuFYXmUwfvLqhaLptxnsbi6/DiT xbON81ksPix8yGJx6mgzowOrx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CVsffEJLaCHvGK z7cfsTYwHhDrYuTkkBAwkVj44zpLFyMXh5DAdiaJzpmf2CCcg4wSW6bvZYRwDjFK3Dm4Gso5 ySgxed4zJpB+NgEribf/25lBbBGBIIkf52aAtTMLzGSU6L9+mQ0kISzgKvFxziI2iCI3iQu3 DjBC2EYSLbdWgjWzCKhKvP/xjBXE5hXwkngy5zhYjZCAi0TX/3PsIDYn0JxHxzeB2YwCYhLf T60BO4JZQFzi1pP5TBAPCUgs2XOeGcIWlXj5+B8rhG0gsXXpPhYIW0Fi+/5tQDYHUK+mxPpd +hBjFCWmdD9khzhBUOLkzCcsECdoSey9sQtqjLjE4SM7WCcwSs1CsnkWwqRZSCbNQjJpASPL KkYeSzM9Q0MTPSMLPXOzTYygeC2S8dnB+GmaxyFGAQ5GJR7eGa+XRQmxJpYVV+YCA52DWUmE V/k/UIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv8KOFUUIC6YklqdmpqQWpRTBZJg5OqQZGlqLn K5YuDgnwW/A0N2UiswSD+aYZchue3V0gkHJy36WCrY0v1Z+2dq6QZjtR45rp0+GqYr2iSi5i l0j8cf3duS039tqf/Pnoq9r89jcb2Sd5hm2U2CZZv33H4xLJQm0+jZaiBvObMr0pS1dt8pjz XZlj5m3ZebVnNI8c/97LVP8tV2vB9fJJSizFGYmGWsxFxYkAKMmnedMCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/EQiLBSwfBb4YueA2X0XxYuP4cJk>
Subject: Re: [secdir] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2018 22:36:08 -0000

I'm not opposed to change this to be in that form.  I don't believe this would cause any technical issues.

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

-----Original Message-----
From: Phillip Hallam-Baker [mailto:hallam@gmail.com] 
Sent: Thursday, March 08, 2018 2:39 PM
To: secdir@ietf.org
Cc: uta@ietf.org; draft-ietf-uta-smtp-tlsrpt.all@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

Reviewer: Phillip Hallam-Baker
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

General comments:

Five minutes after I received the review request, a very similar proposal was made in CABForum for reporting PKIX cert issues.

The Security Considerations section proposes use of DNSSEC, what happens if that is misconfigured? Well it should be reported.

The logic of this proposal is that something like it become a standard deliverable for a certain class of service specification. I don't think we should delay this and meta-think it. But we should anticipate it being joined by others like it sharing syntax, DDoS mitigation, etc.

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.

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

v2.23.0 | Report a Bug | By Email