The primary motivation for using tls is opportunistic security. Authentication would be interesting to add. SNI encryption would be interesting but I think is a separate topic. Client authorization might be useful in some cases, but generally is not done in DNS servers. To address these would require a security analysis of much broader scope than is appropriate for this document. We’ve talked about this in the context of homenet. Sent from my iPhone > On Jun 15, 2019, at 12:47 PM, Tom Pusateri <pusateri@xxxxxxxxx> wrote: > > Does this address your concerns? > >> On May 17, 2019, at 11:59 AM, Tom Pusateri <pusateri@xxxxxxxxx> wrote: >> >> Will also address TLS comments. >> >>> 3. In the section of Security Considerations: >>> 1) you should also mention that TLS provides the anti-replay protection >>> service for DNS Push; > > I have added a 4th security service in the Security section: > > Anti-replay protection: TLS provides for the detection of and > prevention against messages sent previously over a TLS connection > (such as DNS Push Notifications). Prior messages cannot be re- > sent at a later time as a form of a man-in-the-middle attack. > >>> 2) maybe you need to consider the client >>> authentication to achieve policy control and detect illegal client; > > I have added a new paragraph in the Security section: > > As a consequence of requiring TLS, client certificate authentication > and verification may also be enforced by the server for stronger > client-server security or end-to-end security. However, > recommendations for security in particular deployment scenarios are > outside the scope of this document. > >>> 3) TLS >>> WG are specifying the SNI encryption mechanism, will it influence your TLS >>> name authentication? > > SNI encryption has no effect on our use of TLS name authentication. > > Thanks, > Tom > > > _______________________________________________ > dnssd mailing list > dnssd@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dnssd
