On Aug 19, 2014, at 6:56 AM, Hosnieh Rafiee <[email protected]> wrote:
> Hi Paul, > >> Greetings. I created a new proposal on a simple way to do DNS over TLS >> between stubs and resolvers. Comments are appreciated. >> > > I read your draft and have some questions as followings: > > Section 2. "If the recursive resolver > responds on port 443, both the client and the server MUST use the > ALPN [RFC7301] extension to TLS, and MUST use "dns" as the > identification sequence in ALPN." > > Still the nodes are in processing the hello client exchange and the > encryption was not happened. As you explained in your draft, opportunistic > security is in use. In other words, the server might not have certificate > that is signed by a CA. In this case how the client or server react when an > attacker intercept this communication and change "dns" to something else? I'm not sure how to interpret your question. If there is an MITM who wants to watch the DNS traffic, why would they change the ALPN name to prevent DNS from passing? > IMHO, there is a missing explanation of the case where this ALPN changes. I can add that if I understood what it might change to. > You explained in "security consideration" section that ALPN is only for > applications to identify this protocol and normally by port numbers this > protocol would be verified ????? The security considerations say nothing about ALPN. > but I guess you have used one of popular port for TLS. Now the question is > that if an attacker has an opportunity to change this ALPN, what will happen? > How your client or server detects that this supposed to be used as resolver > authentication? If both sides are not using ALPN of "dns", then communication doesn't happen. Is that not clear from RFC 7301? > I think there is something important missing in your draft. For resolver's > scenario IMHO, there is two important cases that the first one has a prioriry > over the second one (this is of course my opinion and might not be the same > as others) > 1- authentication > > 2- encryption > > I think authentication for a resolver is essential and more important than > encryption. Because if this authentication cannot be happened then the whole > next security steps will fail. Great! Use the policy knob explicitly listed in section 2.1. > if you cannot always authenticate a resolver because it does not always carry > a valid certificate, the data receives from this resolver is not trusted so > IMHO, opportunistic security is not helpful otherwise you have a method to > verify your resolver. > I agree that opportunistic security would be helpful in some scenarios such > as sending an email to somewhere. Because sending plain text data allow the > exposal of the content of email. But IMHO, in scenarios where authentication > has priority than encryption, opportunistic security is similar to not having > any security. In other words, exposal of domain names are not as important as > verification of the resolver. > > IMHO, opportunistic security is useful for cases where once the attacker > might have an opportunity to retreive data from a user (it only impact on > once communcation) But it is not helpful when it might impact the whole next > communications. This is true for resolver because all the next communication > will be influenced by this first riski step. > > Sorry for my long email, It is not the length that bothers me: it is the attitude of "because I have this policy for my own traffic, the rest of you cannot have better privacy because I don't want the protocol to allow it". --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
