Adrien,

Thanks for your comments.

At 2016-05-03 05:14:31 +0000
"Adrien de Croy" <adr...@qbik.com> wrote:

> Some general comments:
> 
> I don't think you can claim that https provides data integrity or 
> privacy any more, since MitM proxies are abundant.

Can you explain this further?

TLS is designed to provide data integrity and privacy, even in the face
of man-in-the-middle attacks.

> I think some thought should be given to how a DNS stub might deal with a 
> captive portal or http proxy authentication.

I guess this makes sense. I don't know that we can offer much help
though. Perhaps something like this:

    A captive portal or any other middlebox that interferes with HTTP
    may break this protocol, and DNS over HTTP will have to be disabled
    until HTTP is restored.

> I think also that any HTTP server that receives such a request probably 
> ought to be validating the encapsulated binary data before forwarding it 
> to any DNS server.

I rather think this will increase the attack surface area rather than
decreasing it, because now you have an additional place processing DNS
packets.
 
> I wonder why you'd want to keep truncation, as the request should be 
> able to benefit from the fact that fundamentally it's made over TCP to 
> the HTTP agent.

If the client side is acting as a DNS proxy then we need to look like
DNS. The stub resolvers will send UDP packets and expect normal
truncation behavior. While it may be possible for the client DNS proxy
to perform truncation and send responses back to the stub resolvers,
this is a significantly more complicated design.

> I would also suggest looking into how such requests might be best 
> blocked by an http proxy, because this will be a requirement of proxy 
> operators, and it would be good to consider user experience for when 
> this happens, so that a consistent approach can be taken (rather than 
> every different proxy blocking it some other way so that the user 
> experience becomes awful).

In the case of unencrypted HTTP (not recommended), then the proxy can
look for the well-known URI, right?

In the case of TLS, then the proxy cannot block the traffic, can it? It
doesn't know the URI that the site is visiting, nor the contents of the
query or answer....

Cheers,

--
Shane

Attachment: pgp0bSsqxcejH.pgp
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to