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