Re: [DNSOP] [dnsext] CGA-TSIG - new version

"Hosnieh Rafiee" <> Sun, 16 February 2014 14:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 043581A0225; Sun, 16 Feb 2014 06:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id maDieItrSixU; Sun, 16 Feb 2014 06:51:28 -0800 (PST)
Received: from ( [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by (Postfix) with ESMTP id 682F61A0238; Sun, 16 Feb 2014 06:51:28 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 476F823E2D48; Sun, 16 Feb 2014 14:51:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gyYtgSZbJGyu; Sun, 16 Feb 2014 15:51:18 +0100 (CET)
Received: from kopoli ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 80A4F23E2B25; Sun, 16 Feb 2014 15:51:18 +0100 (CET)
From: "Hosnieh Rafiee" <>
To: "'Marc Buijsman'" <>
References: <021201cf29d9$8a5daa30$9f18fe90$> <> <003a01cf2b0c$067d2360$13776a20$> <003b01cf2b10$091fbde0$1b5f39a0$> <>
In-Reply-To: <>
Date: Sun, 16 Feb 2014 15:51:16 +0100
Message-ID: <005c01cf2b26$8b895aa0$a29c0fe0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHoCE4W3igGmux4JlwPGjTA=
Content-Language: en-us
Cc: 'Jeroen van der Ham' <>,,
Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version
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: Sun, 16 Feb 2014 14:51:31 -0000

Dear Marc,

Thanks again for your message.
> Let me first react to your first email of today. CGA uses the
> RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I
> understand it as explained at
> is that the length of the
> output signature S only depends on the length k of the RSA modulus n, and
> not on the length of the input message M. The algorithm accomplishes this
> using a hash function on message M, SHA-1 in case of CGA. So provided that
> the RSA key has been determined, it does not matter how many fields you
> concatenate and take as input message M (although there is a maximum
> depending on the chosen hash function); the output will always be a
> of length k. The signature field is variable because the RSA key size is
> not because the message is variable.

You're right I guess I was confused two different things -- data encryption
and  signature generation. I re-checked the signature generation algorithm.
Since first the data is hashed using SHA function and then the digest is
encrypted using a private key, this will lead to having the same length

But I need to update the document that the signature should be generated
based on the standard RSASSA-PKCS1-v1_5 or for ECC (as a future replacement
of RSA) there should be a standard way. Because I think it is necessary to
also consider other SHA algorithms since SHA1 is no longer consider a very
strong hash function and CGA-TSIG needs to support any future changes to
other algorithms.

> I was not aware that SEND actually encodes groups of 8 bytes. I thought
> meant that the value set in the length field should be a multiple of 8,
but now I
> see you mean that the length of the data itself should be a multiple of 8.
It is
> then logical that you might need padding to be able to make whole
> 'octobytes'. However, I don't believe that this padding is needed for the
> signature operation since the hash function takes a variable amount of
> bytes anyway. You also didn't mention anything about padding in your draft
> (nor does the CGA RFC), so I assumed the encoded length to be in bytes
> like the other length-encoding fields in the TSIG RR. I'm also not sure if
> save more space by using 1 byte for the length-encoding field and
> padding, instead of 2 bytes for the length-encoding field without padding.

IMHO, we do not really need two bytes and no padding is also needed. Because
I think if the encryption is on hash function, then it always generates the
same values that is multiple of 8. To have a proof of concept, I checked RSA
signature a few minutes ago with different key sizes (1024bits , 1280bits,
1536bits, 1792bits,2048bits, 3072bits) and the result was always the
multiple of 8. 

> Regarding the old signature, I think you could even leave out the
> from the old signature operation. As long as you sign the new public key
> the old public key (with the old signature as ouput) in order to
> the new public key, it is also possible to authenticate the timestamp and
> field provided that they have been signed with the new public key (as
> required by TSIG, which recommends a fudge value of 300 seconds i.e. 5
> minutes, a bit more than a few seconds).

Hum... I guess you're right. Signing only the new public key is enough and
in this case no timestamp is needed for the old signature (not new
signature).  I know the attacker only has a small period of time to do this
attack and if it cannot do it, since the new public key is replaced with the
old one on the DNS server, it cannot do this attack anymore or this attack
is not effective as there is no old public key anymore valid.
So I assume this scenario can be like this:
The original node wants to change its IP address or public key. It signs all
DNS message excluding the signature fields using its own new private key and
sign the new public key using its own old private key. Then submit this
packet including the TSIG RR with CGA-TSIG  DATA

The attacker eavesdrops and copy only the old public key and old signature
from the packet and sign the DNS message using its own private key and
submit this value... But the verification of the old signature fails since
the attacker cannot copy the new public key of the original node. If it does
this, the CGA verification will be failed and the node cannot prove the
owner of this public key.

By assuming such failure in the attack scenario. I guess only signing the
new public key for old signature is enough. For this purpose no more
authentication is needed since the time has been already checked for the new