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

[Marc Buijsman <[e-mail]>]

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

Hosnieh Rafiee schreef op 15-2-2014 0:07:
> 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:[e-mail]] On Behalf Of Marc Buijsman
>> Sent: Thursday, January 16, 2014 3:45 PM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsext