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

"Hosnieh Rafiee" <ietf@rozanak.com> Mon, 24 February 2014 20:33 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 144821A0202; Mon, 24 Feb 2014 12:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level:
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 k1TsaGAWGo1l; Mon, 24 Feb 2014 12:33:15 -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 585CB1A02E1; Mon, 24 Feb 2014 12:33:15 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id C143E23E2D51; Mon, 24 Feb 2014 20:33:13 +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 jF-RQx93clJU; Mon, 24 Feb 2014 21:33:09 +0100 (CET)
Received: from kopoli (g225058231.adsl.alicedsl.de [92.225.58.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EF72523E24C1; Mon, 24 Feb 2014 21:33:08 +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> <000f01cf2b5b$a26b6800$e7423800$@rozanak.com>
In-Reply-To: <000f01cf2b5b$a26b6800$e7423800$@rozanak.com>
Date: Mon, 24 Feb 2014 21:33:03 +0100
Message-ID: <00ba01cf319f$a10e6530$e32b2f90$@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/eRXQgH21IMfltmoiXA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/uOhEmgWxzI_BRTCNNTnrIXQXSkM
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: Mon, 24 Feb 2014 20:33:20 -0000

Dear Marc,
Do you have any other comments or I could address your concerns?

Thanks,

Best,
Hosnieh

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
> Sent: Sunday, February 16, 2014 10:11 PM
> To: 'Marc Buijsman'
> Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dnsext@ietf.org
> Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version
> 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop