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

[Phillip Hallam-Baker <[e-mail]>]

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 <
[e-mail]> 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:[e-mail]]
> Sent: Thursday, March 08, 2018 2:39 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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/