Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig

Sam Hartman <> Tue, 19 February 2013 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4353E21F887F for <>; Tue, 19 Feb 2013 15:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.834
X-Spam-Status: No, score=-102.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ncP-PhtitbGN for <>; Tue, 19 Feb 2013 15:39:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 944B921F87EE for <>; Tue, 19 Feb 2013 15:39:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id CD19920161; Tue, 19 Feb 2013 18:34:35 -0500 (EST)
Received: by (Postfix, from userid 8042) id A0A5A440A; Tue, 19 Feb 2013 18:39:07 -0500 (EST)
From: Sam Hartman <>
To: Sean Turner <>
References: <>
Date: Tue, 19 Feb 2013 18:39:07 -0500
In-Reply-To: <> (Sean Turner's message of "Tue, 19 Feb 2013 15:40:48 -0500")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Ralph Droms <>,
Subject: Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Feb 2013 23:39:15 -0000

I took a look at draft-rafiee-intarea-cga-tsig.

The idea is generally sound although I did not fully debug the algorithm
as discussed below. Unfortunately, the draft needs a lot of work before
it's ready.


Section 3 contains a number of claims regarding protecting the exchanges
between the resolver and client. Is tsig actually used for DNS
resolution or just for update/zone transfer?
Section 3 should be reviewed to determine whether all the use cases are
in fact applicable for use of tsig.

The draft really needs help from someone with an eye towards
Section 4 repeates much of the key generation from the CGA specification
and repeats a lot of detail from the TSIG specification as well.
The rest of the draft tends to suffer from this as well.

Unfortunately, that approach--repeating (and sometimes changing) text
from CGA and TSIG is highly problematic. It makes it hard to evaluate
correctness of this specification and to identify all the differences
between this specification and the existing specifications.  In
addition, it makes it hard to understand how this specification might
interact with existing extensions to CGAs and existing or future
extensions to DNS-TSIG.

Please ask someone from the DNS community to review the shortening of
the TSIG exchange and the removal of the TKEY RR type.

The general textual clarity could be significantly improved.

I don't think this draft is ready for adoption, but I do think that the
ideas expressed here could be a valid basis for future work.