Re: [DNSOP] my dnse vision

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch <[e-mail]> wrote:

> Phillip Hallam-Baker <[e-mail]> wrote:
> >
> > First off it means that if the recursive is being used in discovery-only
> > mode it can simply pass data from the authoritative to the stub without
> > checking the DNSSEC chain.
>
> If the recursive server is cacheing it needs to do DNSSEC validation to
> protect its cache from poisonous authorities.


But that would be an offline activity rather than within the response loop
to service the request from the stub.

> Resolver is connecting to an authoritative to make a request
> > really-obvious.com to answer a query from a stub (i.e. this is not a
> > pre-fetch).
> >
> > Resolver has no session key on file so it sends the request in plaintext.
>
> This leakage is bad expecially for recursors with few users and / or
> queries for infrequently visited domains.


If a Russian citizen is visiting Putler.com and the authoritative for that
zone only has that entry and nothing else, then traffic analysis is going
to give away the request subject.

That is just something we have to live with, lessons in not being seen and
all that.



> > It can however be alerted to support for the security protocol in the
> > DNSSEC information for the zone.
>
> This is a bad idea because it makes partial deployment difficult - e.g.
> staged roll-out of encryption. DNSSEC information is per-zone but
> encryption has to be per-server.


I can't see the point of a partial rollout of encryption at an
authoritative. But worst case it just means that the client is going to
assume the service does not support encryption until it sees an EDNS record
saying that it does.

In the example I was trying to show what the maximal cover we could achieve
for this case might look like. Obviously if there is even one authoritative
that isn't encrypting we don't need to worry about odd
secure-after-first-contact requests that go unencrypted.


The other reason to tie the signalling to DNSSEC is that it then avoids
people getting confused about the authentication being proposed here as
being an alternative to the authentication in DNSSEC. It isn't an either/or
situation. We need both sets of authentication controls.

-- 
Website: http://hallambaker.com/