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

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 15 Feb 2014 00:07:31 +0100

Thanks for the information you've provided, I improved the document
according to comments and found out that the report also has a few problems
which is due to the fact that it misinterpreted the of CGA-TSIG document.

Here I explain the problems or the reasons of choices:

- CGA-TSIG cannot use MAC as a signature field. The purpose was that to have
all the CGA data in one section instead of trying to find them in different
sections of TSIG. 

- sizes of length encoding: It is one byte. It is enough for any key sizes.
If you also check the "checksum" field in the packets, you will find out
that it is only 8 bits or one byte. In the emails I explained to you that it
is the multiple of 8. In no RFC you can find out that the value is the
length of data in bits. It is always the length of data in bytes. But how
you showed in your report is that you consider the number of bits and not
bytes so you had the following example
2048/8=256 (now you only converted the number of bits to bytes) so you
needed to divide it by another 8 that is 256/8=32 and this is the value you
set to length. If you even consider the key size 7680, then the length will
be only 120.
nd
- old signature only contains time signed. The reason is to avoid increasing
the packet length 

I appreciate further comments and would like more people review it so that
we can go ahead with this document.

Thanks,
Hosnieh

A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt
has been successfully submitted by Hosnieh Rafiee and posted to the IETF
repository.

Name:		draft-rafiee-intarea-cga-tsig
Revision:	07
Title:		Secure DNS Authentication using CGA/SSAS Algorithm in IPv6
Document date:	2014-02-15
Group:		Individual Submission
Pages:		26
URL:
http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt
Status:
https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/
Htmlized:       http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07
Diff:
http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07

Abstract:
   This document describes a new mechanism that can be used to reduce
   the need for human intervention during DNS authentication and secure
   DNS authentication in various scenarios such as the DNS
   authentication of resolvers to stub resolvers, authentication during
   zone transfers, authentication of root DNS servers to recursive DNS
   servers, and authentication during the FQDN (RFC 4703) update.

   Especially in the last scenario, i.e., FQDN, if the node uses the
   Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the
   Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has
   no way of updating his FQDN records on the DNS and has no means for a
   secure authentication with the DNS server. While this is a major
   problem in NDP-enabled networks, this is a minor problem in DHCPv6.
   This is because the DHCP server updates the FQDN records on behalf of
   the nodes on the network. This document also introduces a possible
   algorithm for DNS data confidentiality.

> -----Original Message-----
> From: dnsext [mailto:[email-masked]] On Behalf Of Marc Buijsman
> Sent: Thursday, January 16, 2014 3:45 PM
> To: [email-masked]
> Cc: Jeroen van der Ham
> Subject: [dnsext] CGA-TSIG research report
> 
> Dear working group members,
> 
> For my master's thesis I have performed an investigation at NLnet Labs on
> CGA-TSIG as a solution to the last mile problem of DNS. The version of the
> CGA-TSIG proposal that I reviewed is the current latest version at
> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During the
course of
> my research I have already had some contact with Ms. Rafiee.
> 
> In order to do a verification of the CGA-TSIG proposal I have created a
proof
> of concept implementation in NLnet Labs' "ldns" library. Since the scope
of
> the project was limited to the last mile problem it only includes the code
> required for this purpose, but the implementation could easily be extended
> to support other applications (like zone transfers). I have found that
CGA-TSIG
> has potential to be an adequate solution to the last mile problem on IPv6
> networks, although some future research is needed with regard to
> bootstrapping the authentication.
> 
> As a result, I would hereby like to refer you to my report which can be
found
> at http://www.nlnetlabs.nl/downloads/publications/report-rp2-buijsman.pdf.
> I have outlined my results in section 4.2 which contains suggestions on
how I
> believe the CGA-TSIG draft could be clarified and otherwise improved. I
hope
> my suggestions will be adopted in the next version of the draft. The PoC
code
> can be found in the online Git repository of NLnet Labs at
> http://git.nlnetlabs.nl/ldns/?h=cga-tsig.
> 
> I hope my work will be helpful in standardising CGA-TSIG.
> 
> Yours sincerely,
> 
> Marc Buijsman
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Marc Buijsman <[email-masked]>
Date: Sun, 16 Feb 2014 12:11:58 +0100

Dear Hosnieh,

First of all, I'm glad I could be of help and to see that a number of my
suggestions have been adopted!

Regarding the size of the length fields, however, I'm still confused by
what you are trying to say. I did not consider the number of bits, I
really considered the number of bytes (octets). If I wanted to encode
the length in bits (and I don't), I would have set the value to 2048.
But I'm dividing by 8 and set the value to 256 instead, which is the
length in *bytes* as you said yourself. The reason why you divide by 8 a
second time is a mystery to me. The outcome would then be the number of
groups of 8 bytes, but I've never seen a length encoding before that
counts such 'octobytes' (which is not a byte, but 8 bytes). So you are
counting 32 octobytes, while I am counting 256 bytes (as usual).

Also, I don't understand what you mean to say by "multiple of 8". If the
encoding would be in bits (and again, it's not) and the data is always a
number of whole bytes, then yes the value would be a multiple of 8. But
we are talking about an encoding in bytes here, which do not necessarily
come in groups of 8 (and is therefore not necessarily a multiple of 8).
I also don't know what checksum fields you mean or how their length is
relevant here, but the IPv4 header checksum field and UDP checksum field
in a regular DNS packet are two bytes each.

With regard to the old signature: how would including more fields in the
digest operation increase the packet size? No matter how many fields you
digest, the resulting signature is always of the same length. And the
fields I was referring to are already part of the packet. In order to be
able to authenticate the new public key, you MUST at least include the
new public key in the digest operation. Otherwise the packet could be
intercepted and the new public key could be replaced without notice.

Kind regards,

Marc Buijsman

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 16 Feb 2014 12:41:26 +0100

Dear Marc,

Thanks for your comments.

> Regarding the size of the length fields, however, I'm still confused by
what you
> are trying to say. I did not consider the number of bits, I really
considered the
> number of bytes (octets). If I wanted to encode the length in bits (and I
don't),
> I would have set the value to 2048.
length in
> *bytes* as you said yourself. The reason why you divide by 8 a second time
is
> a mystery to me. The outcome would then be the number of groups of 8
> bytes, but I've never seen a length encoding before that counts such
> 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32
> octobytes, while I am counting 256 bytes (as usual).

> encoding would be in bits (and again, it's not) and the data is always a
number
> of whole bytes, then yes the value would be a multiple of 8. But we are
talking
> about an encoding in bytes here, which do not necessarily come in groups
of
> 8 (and is therefore not necessarily a multiple of 8).
in
> a regular DNS packet are two bytes each.

http://tools.ietf.org/html/rfc3971#section-5.1
maybe my wording is not correct. Check the length field here. 8 bits is
really not enough for that. So, If you check the implementation of SeNDs
(Docomo, etc). what they do is they shift the values or easier way is to
divide by 8.

> digest, the resulting signature is always of the same length. And the
fields I was
> referring to are already part of the packet. In order to be able to
authenticate
> the new public key, you MUST at least include the new public key in the
digest
> operation. Otherwise the packet could be intercepted and the new public
key
> could be replaced without notice.

You're not talking about SHA1 digest, you're talking about digital
signature. It depends on the input data. This is why , for example, in SeND
they included padding at the end that this value can be the multiple of 8.
If this value had a fixed size, they would not include any length to it. In
RFCs they usually include lengths when the length of value is variable and
without length field, one cannot determine the length.
http://tools.ietf.org/html/rfc3971#section-5.2
So, this value is not actually the same size and depends on the plain text
that one wants to sign. 
Secondly, if you check the content of the signature, you will notice that I
included all the DNS message and it is not like before. Because the new
signature is verified before old signature, no replay attack can be happened
since the new signature verification will be failed. So no need to sign a
large data for old signature field and only timestamp or a small value is
enough just to show that this node is the owner of this public key. To avoid
replay attack again, I consider to sign the timestamp.

I hope this answer your questions.

Thanks,
Best,
Hosnieh

> > according to comments and found out that the report also has a few
> > problems which is due to the fact that it misinterpreted the of CGA-TSIG
> document.
> >
> > - CGA-TSIG cannot use MAC as a signature field. The purpose was that
> > to have all the CGA data in one section instead of trying to find them
> > in different sections of TSIG.
> >
> > If you also check the "checksum" field in the packets, you will find
> > out that it is only 8 bits or one byte. In the emails I explained to
> > you that it is the multiple of 8. In no RFC you can find out that the
> > value is the length of data in bits. It is always the length of data
> > in bytes. But how you showed in your report is that you consider the
> > number of bits and not bytes so you had the following example
> > needed to divide it by another 8 that is 256/8=32 and this is the
> > value you set to length. If you even consider the key size 7680, then
> > the length will be only 120.
> > nd
> > - old signature only contains time signed. The reason is to avoid
> > increasing the packet length
> >
> > I appreciate further comments and would like more people review it so
> > that we can go ahead with this document.
> >
> > Thanks,
> > Hosnieh
> >
> >
> >
> > has been successfully submitted by Hosnieh Rafiee and posted to the
> > IETF repository.
> >
> > Htmlized:
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07
> >> For my master's thesis I have performed an investigation at NLnet
> >> Labs on CGA-TSIG as a solution to the last mile problem of DNS. The
> >> version of the CGA-TSIG proposal that I reviewed is the current
> >> latest version at
> >> the project was limited to the last mile problem it only includes the
> >> code required for this purpose, but the implementation could easily
> >> be extended to support other applications (like zone transfers). I
> >> have found that
> > CGA-TSIG
> >> has potential to be an adequate solution to the last mile problem on
> >> IPv6 networks, although some future research is needed with regard to

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 16 Feb 2014 13:10:08 +0100

Follow up,

I thought again about the possible attacks scenarios. I concluded that I
also need to include the new public key in the content of the old signature.
This means the old signature should be "new public key + timestamp",
otherwise the attacker might have a possibility (a few seconds) to do the
replay attack by copying the old public key and oldsignature.  So, you're
right, it still might cause the attacker to attack. But to avoid increasing
packet size, it is only enough for the two values that is new public key and
timestamp. Since the new public key is verified by both CGA verification
process and also the new signature and the old public key is verified by old
signature.

I will correct this in the next version of the document.

Thanks,
Best,
Hosnieh

> From: dnsext [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
> Sent: Sunday, February 16, 2014 12:41 PM
> To: 'Marc Buijsman'
> Cc: 'Jeroen van der Ham'; [email-masked]; [email-masked]
> Subject: Re: [dnsext] CGA-TSIG - new version
> 
> Dear Marc,
> 
> > Also, I don't understand what you mean to say by "multiple of 8". If
> > the encoding would be in bits (and again, it's not) and the data is
> > always a
> number
really
> not enough for that. So, If you check the implementation of SeNDs (Docomo,
> etc). what they do is they shift the values or easier way is to divide by
8.
> 
> > With regard to the old signature: how would including more fields in
> > the digest operation increase the packet size? No matter how many
> > fields you digest, the resulting signature is always of the same
> > length. And the
> fields I was
signature. It
> depends on the input data. This is why , for example, in SeND they
included
> padding at the end that this value can be the multiple of 8.
> If this value had a fixed size, they would not include any length to it.
In RFCs
> they usually include lengths when the length of value is variable and
without
> length field, one cannot determine the length.
that
> one wants to sign.
large
> data for old signature field and only timestamp or a small value is enough
just
> to show that this node is the owner of this public key. To avoid replay
attack
> again, I consider to sign the timestamp.
> 
> > > to have all the CGA data in one section instead of trying to find
> > > them in different sections of TSIG.
> > >
> > > you that it is the multiple of 8. In no RFC you can find out that
> > > the value is the length of data in bits. It is always the length of
> > > data in bytes. But how you showed in your report is that you
> > > consider the number of bits and not bytes so you had the following
> > > example
> > > 2048/8=256 (now you only converted the number of bits to bytes) so
> > > you needed to divide it by another 8 that is 256/8=32 and this is
> > > the value you set to length. If you even consider the key size 7680,
> > > then the length will be only 120.
> > > nd
> > > I appreciate further comments and would like more people review it
> > > so that we can go ahead with this document.
> > >
> > > Thanks,
> > > Hosnieh
> > >
> > >
> > >
> > > http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07
> > > .t
> > > xt
> > > Status:
> > >> the project was limited to the last mile problem it only includes
> > >> the code required for this purpose, but the implementation could
> > >> easily be extended to support other applications (like zone
> > >> transfers). I have found that
> > > CGA-TSIG
> > >> IPv6 networks, although some future research is needed with regard
> > >> to bootstrapping the authentication.
> > >>

---

From: Marc Buijsman <[email-masked]>
Date: Sun, 16 Feb 2014 14:01:58 +0100

Dear Hosnieh,

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.

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.

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

Kind regards,

Marc Buijsman

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 16 Feb 2014 15:51:16 +0100

Dear Marc,

Thanks again for your message.
> 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

---

From: Marc Buijsman <[email-masked]>
Date: Sun, 16 Feb 2014 21:09:07 +0100

Dear Hosnieh,

> encrypted using a private key, this will lead to having the same length

I'm glad you agree. :)

> strong hash function and CGA-TSIG needs to support any future changes to

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.

> 1536bits, 1792bits,2048bits, 3072bits) and the result was always the

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.

> authentication is needed since the time has been already checked for the new

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

Thank you!

Kind regards,
Marc Buijsman

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 16 Feb 2014 22:11:17 +0100

Dear Marc,

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

> 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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 24 Feb 2014 21:33:03 +0100

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

Thanks,

Best,
Hosnieh

> From: DNSOP [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
> Sent: Sunday, February 16, 2014 10:11 PM
> To: 'Marc Buijsman'
> Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version
> 
> Dear Marc,
> 
> 
> > > 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.
> > 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
> > 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
> 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.
> 
> 
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.
also
> inform the clients about any changes of the DNS information such as the
DNS
> IP addresses.
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.
> 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.
> 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
> 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.
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Marc Buijsman <[email-masked]>
Date: Mon, 24 Feb 2014 22:37:22 +0100

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