On 12/13/2011 12:33 AM, Bhatia, Manav (Manav) wrote: >>> Ok, let me put it this way. I was trying to propose extending NTP to >> support having an arbitrary MAC size. I was also trying to >> push HMAC-SHA-1, instead of the regular SHA-1. >> >> That's one possibility. Another is SHA-2. That's why we need >> to revisit the question. > > Security vulnerabilities found in SHA-1 and SHA-2 don't apply to HMAC-SHA-1 and HMAC-SHA-2. I understand that the known attacks on SHA-1 and SHA-2 will not apply to NTP (like most IETF protocols) but that doesn't mean that we should go ahead using them. The security ADs I believe are insistent on the HMAC construct to be used. To cite an example, Bidirectional Forwarding Detection (BFD) protocol already supports SHA-1. It is however being upgraded to support the HMAC version of the SHA algorithms. I thus don't recommend going ahead with SHA-2.
Sorry, I managed to miscommunicate what I meant. If HMAC is what is needed to be used then we should use it. I just threw out SHA-2 as an example. It wasn't meant as a specific recommendation. There are several parts to the requirements about the MAC: 1) Signalling by the sender what algorithm to use for the MAC in the packet; 2) Signalling by the requestor what algorithms it can accept since the two ends may have support for different algorithms. 3) What to do in the case where there is no algorithm in common. Danny > Cheers, Manav _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
