Re: [DNSOP] my dnse vision

Phillip Hallam-Baker <> Mon, 10 March 2014 17:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80A461A0648 for <>; Mon, 10 Mar 2014 10:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PGUDmkvLkKs9 for <>; Mon, 10 Mar 2014 10:36:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::229]) by (Postfix) with ESMTP id 792491A04AC for <>; Mon, 10 Mar 2014 10:36:20 -0700 (PDT)
Received: by with SMTP id gl10so4869005lab.14 for <>; Mon, 10 Mar 2014 10:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gON/Uigyx/LYDstxUZspFFT2mdOncYbcUNN1x/1A0EE=; b=s8Pz0ZhY2+D+5LHT6I69aS7EjjEJinJwyWU/E1fR7AWZ/sDBhdbddfmvW5kU8I2gzN Wj+4Gt2MJ7Lw/DVS031onQOKZ9bGxOEuLMB43BVVvTUnH3EKproqmsrzbTHuSD8rE7WZ zcCVHc0+01OR4CTeiwZ6Cm2rlBlSevoTDK9v6af5xtGp4gSL6wrA/cxrfBctAXnUuPEI CWxqN8S9iHioQ4+ctfmnBhYegFpTCSwGtEK1JG6lNJesLg/1Aawk5h0o7XCKw9MB8VIP glvl0YKboDg/fTVCtvQLAPqIU5Sd3uxFUfrp/k2Aov8WT3DiFMy5oY+whzlR5tIRtpEB PWxg==
MIME-Version: 1.0
X-Received: by with SMTP id g4mr2348913lbf.47.1394472974453; Mon, 10 Mar 2014 10:36:14 -0700 (PDT)
Received: by with HTTP; Mon, 10 Mar 2014 10:36:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 10 Mar 2014 13:36:14 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Tony Finch <>
Content-Type: multipart/alternative; boundary=14dae9473ba34a903304f4440aef
Cc: "" <>
Subject: Re: [DNSOP] my dnse vision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Mar 2014 17:36:23 -0000

On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch <> wrote:

> Stephane Bortzmeyer <> 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 to answer a query from a stub (i.e. this is not a

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: ? A
      TICKET = {NULL, key}

Authoritative [Encrypt, Sign under Key] =  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.