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

"Hosnieh Rafiee" <> Sun, 16 February 2014 21:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D824C1A041B; Sun, 16 Feb 2014 13:11:29 -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 kN0evIwLRFyv; Sun, 16 Feb 2014 13:11:25 -0800 (PST)
Received: from ( [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by (Postfix) with ESMTP id 4C7F41A02E5; Sun, 16 Feb 2014 13:11:25 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 7DDC223E2D48; Sun, 16 Feb 2014 21:11:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mngg6NlyLpWw; Sun, 16 Feb 2014 22:11:20 +0100 (CET)
Received: from kopoli ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1A2B923E2B25; Sun, 16 Feb 2014 22:11:20 +0100 (CET)
From: "Hosnieh Rafiee" <>
To: "'Marc Buijsman'" <>
References: <021201cf29d9$8a5daa30$9f18fe90$> <> <003a01cf2b0c$067d2360$13776a20$> <003b01cf2b10$091fbde0$1b5f39a0$> <> <005c01cf2b26$8b895aa0$a29c0fe0$> <>
In-Reply-To: <>
Date: Sun, 16 Feb 2014 22:11:17 +0100
Message-ID: <000f01cf2b5b$a26b6800$e7423800$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHoCE4W3igGmux4JAfAtHs4C/eRXQpbc0RYg
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 21:11:30 -0000

Dear Marc,

> Yes, that's what I thought too, so that's why I proposed to use
> 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1.
> > 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.
> This is indeed true for the signature fields. However, you also defined
> byte length fields for the complete CGA-TSIG DATA field, the Parameters
> and the Old PK field (not in the table in section 4.1 of draft 07, but you
do in
> the figure in section 4.2). The Parameters field includes the public key,
> consists of (for example) an 1024-bit modulus, but also of a variably
> exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding.
> According to my calculations, this requires a minimum of 161 bytes for the
> complete DER-encoded public key. If you then add the 16-byte modifier, the
> 8-byte prefix, the 1-byte collision count, and 0 bytes for the extension
> (but this one is variable as well), then you get a total size of 186 for
> Parameters field, which is not a multiple of 8. You would then need
> 6 bytes of additional padding, or fiddle with the padding inside the DER
> structure (but I don't think this is desirable).
> Assuming that the Old PK is also a DER-encoded ASN.1 structure and that an
> Old PK of similar size is added to the packet (161 + 7 bytes padding),
then the
> complete CGA-TSIG DATA field would be of size 660 (including 22 bytes for
> the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two
> signatures of length 128), which requires an additional padding of 4 bytes
> make it a multiple of 8.

> So the total padding in this case would be 6 + 7 + 4 = 17 bytes.
> However, if you would use 2 bytes for all five length fields then you
> need padding and you would actually spare 17 - 5 = 12 bytes. To be honest,
> don't think the difference is significant enough with respect to the total
size of
> 664 bytes to make it a strong argument for using 2-byte length fields, but
I do
> think that it makes implementing CGA-TSIG much more straightforward
> without having the hassle of adding paddings to each variably sized field.
> would also be in line with the size of the length fields defined by TSIG,
> are also 2 bytes.

Agreed. For CGA-TSIG data structure, I will change it but for signatures, I
will let it to be only 8 bits since it does not need it.

> Agreed. That only leaves the problem of how you notify your clients of
> new IPv6 address. :)

It is also not a problem. I addressed it in the new version. The client
receives the IP address of the DNS server from the option of the router
advertisement (if it wants to be secure) and this is the recommended way.
So, the routers usually sends the RA message in a frequent intervals. This
also inform the clients about any changes of the DNS information such as the
DNS IP addresses. 

I just explain a possible attack scenario here

A node receives a RA message and after verification accepts that router
prefix and also sets its DNS IP address (resolver A). Whenever it wants to
resolve any domain names, it asks the resolver A to translate a domain to an
iP address.

Now consider a case where resolver A changes its IP address for whatever
reason. If we say that the RA message interval is 10 minutes. The node now
wants to resolve a name and since it hasn't yet received any new RA message,
it sends a message to the old resolver. We assume that the attacker can
eavesdrop this message. He immediately answers instead of legitimate
resolver (since there is no resolver using that old IP address). The
resolver, according to CGA-TSIG document, needs to include the CGA-TSIG data
structure that enables the other nodes to verify it. Since the attacker does
not have the private key of the legitimate resolver, it cannot spoof the old
IP address of the legitimate resolver since the CGA verification will fails
and signature is not valid if the time signed is an old time.  So, this
attack fails. But only the problem is that the node needs to either wait for
another RA message to receive the new information about the resolver or can
send a RS message and ask for a new RA message to save time. This can happen
after the node does not receive any response from the legitimate resolver.
It then assumes that the legitimate resolver is not alive anymore. 

The other way to solve this problem is that. The resolver announce the nodes
who wants to communicate, about the changes in its IP address. But this is
more complicated than the first solution. Because, the node should know when
the resolver wants to change its IP address. However, we can decrease the
complexity by having a default standard value. Say something like 10
minutes. So, if the resolver receives any query request 10 minutes before
changing its IP address, it will include the its old IP address as mentioned
in CGA-TSIG document. This inform the nodes that the resolver's old IP
address will not be valid after 10 minutes and they need to replace this IP
for further communication in their cache.

The last solution would be using both approach to ensure the client can
translate the names to IP without any delay to go through sending RS and
receiving RA, etc.