Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Thu, 11 Jul 2019 at 05:55, Paul Hoffman <[e-mail]> wrote:

> On Jul 9, 2019, at 3:46 AM, tirumal reddy <[e-mail]> 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