Subject: [secdir] secdir review of draft-cheshire-dnsext-dns-sd

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 13 Nov 2008 17:56:59 -0800

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.

The security consideration section of this document is (in its  
entirety):
> 18. Security Considerations
> DNSSEC [RFC 2535] should be used where the authenticity of  
> information is important. Since DNS-SD is just a naming and usage  
> convention for records in the existing DNS system, it has no  
> specific additional security requirements over and above those that  
> already apply to DNS queries and DNS updates.
I find this inadequate.

With regard to 'authenticity of information', the section doesn't  
discussion when authenticity of information might be important, nor  
does it discuss risks of relying on information in which the  
authenticity is not assured.

While it may well be true that this use of DNS has 'no specific  
additional security requirements', there are likely many DNS security  
issues which apply here and should be discussed here (possibly with  
reference to DNS specifications providing more general discussion of  
the security issues).   In particular, this document recommends  
additional RRs be generated (section 13) but fails to discussion  
security implications and concerns with such generation.

There likely should be some discussion of considerations as when this  
very public discovery mechanism should be used, as opposed to a  
discovery mechanism which only provides discovery to authorized  
entities.

I think that portions of this document could be viewed as  
inappropriately supplanting per-protocol specifications of DNS SRV  
handling, and possibly RFC 2782 itself.   I think the IANA  
registration would be better specified on the standard track, or in a  
BCP.  I also think some of the market drivel (Section 21) should be  
removed.

I would much prefer this to be reworked as a update or replacement of  
RFC 2782.

I've read a number of reviews posted on the IETF list.  I have general  
concerns similar to those posted by Dave Cridland and Ben Campbell.   
In short, this document seems to need more work.

-- Kurt

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir