Re: [DNSOP] [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS

Paul Hoffman <> Sat, 15 February 2014 18:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 76DA71A0272; Sat, 15 Feb 2014 10:36:40 -0800 (PST)
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 Rse3HJgFkTjq; Sat, 15 Feb 2014 10:36:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::234]) by (Postfix) with ESMTP id 0F84B1A026E; Sat, 15 Feb 2014 10:36:37 -0800 (PST)
Received: by with SMTP id ks9so10158172vcb.39 for <multiple recipients>; Sat, 15 Feb 2014 10:36:36 -0800 (PST)
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=r0g6PT4e4OChPqvC0bbwKKMKUvmgpC9Org/zXxNCk3A=; b=ldHiAgXndv1s/jeyvpSSyp09Kh4mkvGaYTKnkx/0VwucGup40CRrOurRCH698dL9dP VDbro1ydKkC6FIOltN55SSZ8R4BNfuqzOmpVH74fi83ZB8vhhkhsadf0cBV82hg8dyYe BGfTCJckeeQ532c6bJOLv7/xtkRP74Ntx9KgTm+0o7IkMEUGk3UBai9McFBjWNVItxT9 abp2tApu7XHJY8GJ0vhjxo8WDNepvqfBbSEXDZ53tHHLphyavfaPx4eBFgBALBK3aXul FI1MuYxSwDpuLyr/IyLlTgUGkxtbcenvEE3nzrzt2BJBlAlp4245xIsR8nWyF4C+IxNj 4y4A==
MIME-Version: 1.0
X-Received: by with SMTP id wx6mr8701267vdc.12.1392489395897; Sat, 15 Feb 2014 10:36:35 -0800 (PST)
Received: by with HTTP; Sat, 15 Feb 2014 10:36:35 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 15 Feb 2014 10:36:35 -0800
Message-ID: <>
From: Paul Hoffman <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary=001a1133ec96cbc96c04f276336c
X-Mailman-Approved-At: Sun, 16 Feb 2014 18:51:55 -0800
Cc: Paul Vixie <>,, perpass <>, Zi Hu <>
Subject: Re: [DNSOP] [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
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: Sat, 15 Feb 2014 18:36:40 -0000

On Sat, Feb 15, 2014 at 8:44 AM, Watson Ladd <> wrote:

> Dear all,
> This proposal has multiple shortcomings compared to DNSCurve.

And some advantages over DNSCurve.

> First off, it says that the rationale for TLS over DNSCurve is simply
> to "take advantage of TLS". I would respectfully submit that DJB can
> do a better job than the TLS committee, and did. Merely adding bolts
> and nuts onto a design is not improving it.

That is a value judgement that cannot be measured. While DJB's crypto
algorithms have been widely adopted, his crypto protocols have not.

Secondly, this proposal only works on TCP. This imposes latency and
> state requirements that most people would rather avoid. The use of
> keepalive only addresses computational burden, not state burden, and
> with the DH speed records we have today unnecessary.

That is a measureable criticism. Note that DNSCurve trades latency and
state for massive amounts more computation by parties who might not care to
do any. Even after many years, there has been no noticeable interest in
DNSCurve from those whom that protocol would hit the hardest.

> Thirdly, this proposal ignores entirely how to validate the server
> over the TLS connection.


> Does it need a certificate?


> Who should be
> allowed to sign it?

"Allowed"? Are we now the identity police?

> How should it be validated?

Using TLS authentication.

> DNSSEC provides a PKI,
> and this proposal provides another one. Their interactions will not be
> fun.

They in fact might be fun; they have barely been explored.

> Fourthly, there is substantial operational knowledge and deployed,
> working, code implementing DNSCurve. This does not hold for this
> proposal.
I question "substantial" and  "operational" at the level that is expected
for this protocol. Regardless, there is substantial operational knowledge
of TLS that dwarfs whatever has been done for DNSCurve.

--Paul Hoffman