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: firstname.lastname@example.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 Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta