Hi Paul, Please see inline
On Wed, 17 Jul 2019 at 21:47, Paul Hoffman <paul.hoff...@icann.org> wrote: > 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? > No, I am not aware of any standard techniques used by endpoints and IoT devices to authenticate the policy information provided by the network ? If you are aware of such techniques, Please share. > > > > 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. > I am not proposing to use Secure DHCP or secure RA. Consider a scenario where an attacker also hosts a resolver and issues policy statements to claim better security and privacy than the one provided the network administrator. How will the client know the policy statement is issued by the resolver deployed by the network administrators or by an attacker ? > 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. > Sure, but I don't see any discussion in the draft explaining how the client determines the future configuration options is coming from a trusted source. If the source cannot be trusted, endpoint can be configured to use a malicious resolver server compromising the endpoint security and privacy, and the future configuration options is not helpful. > > > > 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. > Okay. > > > 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. > CBOR has smaller message size compared to JSON and is faster to process than JSON. Cheers, -Tiru > > --Paul Hoffman
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
