On Jul 17, 2019, at 7:36 AM, tirumal reddy <kond...@gmail.com> wrote: >> One example is that the stub or browser may want to change DoH servers, such >> as if it has discovered one that has a better security policy. >> > Attackers can also host DoH servers and claim they have better security > policy, How will the stub resolver know the server is not lying ?
The same way that they will authenticate any policy information. This is no different than any other policy choice, is it? > > 2) DHCP clients typically have no secure and trusted relationships to DHCP > > servers, how will the client know it is communicating with the recursive > > resolver hosted in the attached network ? > >> It will not. This has always been the problem with DHCP, and efforts to make >> DHCP authenticated have not borne fruit. >> > Yes, but how will the client know it is communicating with an attacker's DoH > server or not ? > In other words, if the client does not securely learn the IP address or > domain name of the resolver, the client could end-up retrieving the > attacker's resolver information. Are you saying that the only way for a client to learn policy information is from secure DHCP or secure RA? It seems like others here disagree with that, and want network administrators to be able to leverage the resolvers under their control to issue policy statements. > Discussing these future configuration options without solving the secure > bootstrapping problem is of little use to implementations and deployments. Others seem to disagree with that statement. > > 4) Any specific reason for picking I-JSON ? > >> Absolutely. I-JSON is more likely to be interoperable than plain JSON: >> that's why it exists. Given that the developers of the clients for this >> protocol will be different than the developers of the servers, greater >> interoperability should be an emphasis. >> > JSON also provides interoperability, please see > https://tools.ietf.org/wg/jose/charters. I-JSON was partially motivated by problems discovered in JOSE. > My other question is why JSON and not CBOR ? CBOR has no advantages in this use case, and JSON is easy to put into master files. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
