On Wed, 13 May 2015 12:36:17 +0200, Simon Josefsson wrote: >Daniel Kahn Gillmor <[email protected]> writes: > >> On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: >>> What I'm basically wondering, and advocating, is if perhaps one method >>> would be sufficient. This would reduce complexity on the protocol and >>> implementation level. >> >> I agree that a single mechanism would be cleaner, but perhaps the two >> mechanisms serve different purposes? >> >> It seems to me that the STARTTLS variant is useful for opportunistic >> dns-privacy, while the distinct-port-based TLS-wrapped variant is useful >> for pre-configured non-opportunistic dns-privacy. > >I think that makes sense -- pre-configured configurations will have some >trust anchor considerations as well, and might as well use a dedicated >port. However these two issues are probably orthogonal. The current >document defines upgrade-base and port-based approach for the same >opportunistic use-case. I'd still like to understand exactly what the >benefit in having two mechanisms that cover the same use-case is.
I would not align choice of startup mechanism with the use case. Choice of mechanism depends on interference or non-interference from the client's first-hop network. Use case (opportunistic vs. pre-configured) depends on the client's policy. Clients that change networks (wifi laptops or phones) will want to be flexible in choice of mechanism, but hopefully consistent in their policy on privacy. When you said: "The current document defines upgrade-base and port-based approach for the same opportunistic use-case.", I would have said "...for all use cases" instead. What in the document suggests mechanism is specific to use case? -John Heidemann _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
