If folk are in London, lets talk to IANA and maybe some DNS folk.

I am pretty sure this is a straightforward issue. But it is one we need to
get right.

On Mon, Mar 12, 2018 at 6:34 PM, Brotman, Alexander <
alexander_brot...@comcast.com> wrote:

> 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:hal...@gmail.com]
> Sent: Thursday, March 08, 2018 2:39 PM
> To: sec...@ietf.org
> Cc: uta@ietf.org; draft-ietf-uta-smtp-tlsrpt....@ietf.org; i...@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

Website: http://hallambaker.com/
Uta mailing list

Reply via email to