[Uta] 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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
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 Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
I concur, I had come to essentially the same conclusion after discussions with IANA. The registry we were looking for was the one Dave had proposed that has not yet been created. I can sync with Dave. It might well be that what we want is a sub registry of the form _smtp._rpt. That way the reporting info for any protocol can be discovered with no need to obtain a per service registration. On Thu, Mar 22, 2018 at 3:17 PM, Alexey Melnikov wrote: > Hi Phillip, > To followup on the IANA issue from your SecDir review: > > On 08/03/2018 19:39, Phillip Hallam-Baker wrote: > > > > 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. > > After looking at this in more details, I think a new registration in the > registry being created by draft-ietf-dnsop-attrleaf is exactly what you > are asking for. I think registering _smtp-tlsrpt there should be > straightforward. However I don't think this document should be delayed > until after draft-ietf-dnsop-attrleaf is done. So if > draft-ietf-dnsop-attrleaf is taking time, the proposed registration can > be moved to draft-ietf-dnsop-attrleaf itself. > > > 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 > > I think this is covered by draft-ietf-dnsop-attrleaf. > > Best Regards, > Alexey > > -- Website: http://hallambaker.com/ ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
