Hi Paul,
Please see inline
On Thu, 11 Jul 2019 at 05:55, Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Jul 9, 2019, at 3:46 AM, tirumal reddy <kond...@gmail.com> wrote:
> > My comments below:
> >
> > 1) Unless a DNS request for <reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO,
> > or a subdomain, as described in Section 2 is sent over DNS-over-TLS
> > (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
> > <reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
> > response is susceptible to forgery.
> >
> > Comment> If the stub resolver is already using DoH with the recursive
> resolver, why does it have to determine the URI template of the DoH server?
>
> 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 ?
>
> > 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 fruti.
>
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.
> > 3)
> > In the future, DHCP and/or DCHPv6 and/or RA may have options that
> > allow the configuration to contain the domain name of a resolver. If
> > so, this can be used for matching the domain name in the TLS
> > certificate.
> >
> > Comment> Same comment as above, Please see
> https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]
>
> That document does not preclude future configuration options. I don't see
> any reason for this spec to do so.
>
Discussing these future configuration options without solving the secure
bootstrapping problem is of little use to implementations and deployments.
> > 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. My other question is why JSON and
not CBOR ?
Cheers,
-Tiru
>
> > 5) The resolver information can also be provided in the server
> certificate itself, for example see
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1
> [tools.ietf.org]. The pros and cons of both approaches need to be
> discussed in the WG.
>
> Agree. If that document progresses, it will certainly have an effect on
> the protocol proposed here.
>
> --Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
