Re: [dnsext] CGA-TSIG - new version

["Hosnieh Rafiee" <[e-mail]>]

Dear Marc,

Thanks again for your message.
> Let me first react to your first email of today. CGA uses the
> RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I
> understand it as explained at
> http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the
> output signature S only depends on the length k of the RSA modulus n, and
> not on the length of the input message M. The algorithm accomplishes this
by
> using a hash function on message M, SHA-1 in case of CGA. So provided that
> the RSA key has been determined, it does not matter how many fields you
> concatenate and take as input message M (although there is a maximum
> depending on the chosen hash function); the output will always be a
signature
> of length k. The signature field is variable because the RSA key size is
variable;
> not because the message is variable.

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.

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.


> I was not aware that SEND actually encodes groups of 8 bytes. I thought
you
> meant that the value set in the length field should be a multiple of 8,
but now I
> see you mean that the length of the data itself should be a multiple of 8.
It is
> then logical that you might need padding to be able to make whole
> 'octobytes'. However, I don't believe that this padding is needed for the
> signature operation since the hash function takes a variable amount of
input
> bytes anyway. You also didn't mention anything about padding in your draft
> (nor does the CGA RFC), so I assumed the encoded length to be in bytes
just
> like the other length-encoding fields in the TSIG RR. I'm also not sure if
you
> save more space by using 1 byte for the length-encoding field and
additional
> padding, instead of 2 bytes for the length-encoding field without padding.

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. 


> Regarding the old signature, I think you could even leave out the
timestamp
> from the old signature operation. As long as you sign the new public key
with
> the old public key (with the old signature as ouput) in order to
authenticate
> the new public key, it is also possible to authenticate the timestamp and
fudge
> field provided that they have been signed with the new public key (as
> required by TSIG, which recommends a fudge value of 300 seconds i.e. 5
> minutes, a bit more than a few seconds).

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.

Thanks,
Best,
Hosnieh