Re: [DNSOP] [dnsext] CGA-TSIG - new version
"Hosnieh Rafiee" <ietf@rozanak.com> Sun, 16 February 2014 21:11 UTC
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D824C1A041B; Sun, 16 Feb 2014 13:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN0evIwLRFyv; Sun, 16 Feb 2014 13:11:25 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7F41A02E5; Sun, 16 Feb 2014 13:11:25 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7DDC223E2D48; Sun, 16 Feb 2014 21:11:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mngg6NlyLpWw; Sun, 16 Feb 2014 22:11:20 +0100 (CET)
Received: from kopoli (g225015008.adsl.alicedsl.de [92.225.15.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1A2B923E2B25; Sun, 16 Feb 2014 22:11:20 +0100 (CET)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Marc Buijsman' <Marc.Buijsman@os3.nl>
References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> <53011AE3.20102@os3.nl>
In-Reply-To: <53011AE3.20102@os3.nl>
Date: Sun, 16 Feb 2014 22:11:17 +0100
Message-ID: <000f01cf2b5b$a26b6800$e7423800$@rozanak.com>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/oFqyOfO5sL7rRMbddV7cWpYLLYg
Cc: 'Jeroen van der Ham' <vdham@uva.nl>, DNSOP@ietf.org, dnsext@ietf.org
Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 single- > byte length fields for the complete CGA-TSIG DATA field, the Parameters field > 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, which > consists of (for example) an 1024-bit modulus, but also of a variably sized > 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 fields > (but this one is variable as well), then you get a total size of 186 for the > 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 to > 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 don't > need padding and you would actually spare 17 - 5 = 12 bytes. To be honest, I > 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. It > would also be in line with the size of the length fields defined by TSIG, which > 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 your > 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. Thanks, Best, Hosnieh
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Marc Buijsman
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Marc Buijsman
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Marc Buijsman
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Hosnieh Rafiee
- Re: [DNSOP] [dnsext] CGA-TSIG - new version Marc Buijsman