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

[Marc Buijsman <[e-mail]>]

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

Hosnieh Rafiee schreef op 16-2-2014 13:10:
> 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