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

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

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

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.

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

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

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