On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch <d...@dotat.at> wrote:
> Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> >
> > The only place where server authentication could be useful is between
> > a stub and the first resolver.
>
> I don't think it is as simple as that.
>
> There are good reasons for using a recursive resolver that is close to
> you, e.g. to avoid untrustworthy shared resolvers. However the more people
> do this the more demand there will be for intercepting iterative queries
> between resolvers and authorities. You need to authenticate authoritative
> servers to protect against active interception.
>
What we are talking about here is cryptographically binding the request and
response under a key.
Since we are going to encrypt we have already agreed to spend the cycles
needed for key setup. So adding a 128 bit MAC only costs us 16 bytes and a
trivial number of cycles.
The benefits we get are significant. 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.
Secondly in the case we have a trusted resolver that is validating the
DNSSEC chain as a proxy for the stub, it means that an attacker can't
meddle with responses as a way to DoS the resolver, possibly causing it to
abort DNSSEC checking completely.
The problem comes in that unlike the stub-resolver interaction where we can
do one key exchange with a service and keep the relationship going for the
life of the device (i.e. years), a resolver has to maintain relationships
with thousands to millions of authoritative servers and we probably can't
rely on these for more than a month or two at a time.
So the key exchange to do the encryption is a bigger cost. It is certainly
justified if we are connecting to the VeriSign or GoDaddy authoritative
servers or for any of the big services. But thats a harder case to make on
the long tail.
What might make sense is to support a symmetric, secure after first use key
exchange as an alternative to using a full public key exchange. We could
further deter intercept as follows:
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.
It can however be alerted to support for the security protocol in the
DNSSEC information for the zone. So assume that there is some flag there
that tells us that we can make a query as follows:
Resolver:
really-obvious.com ? A
TICKET = {NULL, key}
Authoritative [Encrypt, Sign under Key]
really-obvious.com/A = 10.1.2.3
key-exchanger.example.com/PVT WitnessValue
TICKET = {TID, key2}
The ticket returned by the Authoritative {TID, key2} may be used to secure
further requests until a full key agreement has been achieved.
If/when the resolver performs a key exchange, it presents the Witness value
and original key to the key exchange service. This allows the service to
detect an attempt at an active attack.
--
Website: http://hallambaker.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
