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

[Marc Buijsman <[e-mail]>]

Dear Hosnieh,

> 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
> signature.

I'm glad you agree. :)

> 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.

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.

> 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.
>
> So,
> 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
> signature.

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

Thank you!

Kind regards,
Marc Buijsman