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

[Marc Buijsman <[e-mail]>]

Dear Hosnieh,

I have no further comments at the moment. I did not have the chance to
completely read the new version so I was not aware of Section 10, but I
like that you addressed it!

Overall, it is nice to see that the draft has been improved. I hope
others will have a look at it and help improve it more in order to go
forward.

Thanks for thinking along with me, I appreciate it!

Best regards,

Marc Buijsman

Hosnieh Rafiee schreef op 24-2-2014 21:33:
> Dear Marc,
> Do you have any other comments or I could address your concerns?
>
> Thanks,
>
> Best,
> Hosnieh
>
>> -----Original Message-----
>> From: DNSOP [mailto:[e-mail]] On Behalf Of Hosnieh Rafiee
>> Sent: Sunday, February 16, 2014 10:11 PM
>> To: 'Marc Buijsman'
>> Cc: 'Jeroen van der Ham'; [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop