Skip to main content

Last Call Review of draft-ietf-uta-smtp-tlsrpt-17

Request Review of draft-ietf-uta-smtp-tlsrpt
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-02
Requested 2018-03-05
Authors Daniel Margolis , Alex Brotman , Binu Ramakrishnan , Janet Jones , Mark Risher
Draft last updated 2018-03-08
Completed reviews Secdir Last Call review of -17 by Phillip Hallam-Baker (diff)
Genart Last Call review of -17 by Joel M. Halpern (diff)
Genart Telechat review of -18 by Joel M. Halpern (diff)
Assignment Reviewer Phillip Hallam-Baker
State Completed
Review review-ietf-uta-smtp-tlsrpt-17-secdir-lc-hallam-baker-2018-03-08
Reviewed revision 17 (document currently at 23)
Result Has Issues
Completed 2018-03-08
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.