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

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

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


> -----Original Message-----
> From: dnsext [mailto:[e-mail]] On Behalf Of Hosnieh Rafiee
> Sent: Sunday, February 16, 2014 12:41 PM
> To: 'Marc Buijsman'
> Cc: 'Jeroen van der Ham'; [e-mail]; [e-mail]
> Subject: Re: [dnsext] CGA-TSIG - new version
> 
> 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
> 
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext