Re: [secdir] Secdir last call review of draft-ietf-lisp-sec-26

[Luigi Iannone <[e-mail]>]

Hi Alexey,

Please see inline. (I trimmed some text for readability)

> On 8 Jun 2022, at 18:49, Alexey Melnikov <[e-mail]> wrote:
>>> 
>>> Use of SHA-1 is generally not recommended these days, so I would like to understand why you chose to use it. Are there some backward compatibility issues or concerns about size of some fields?
>> 
>> AFAIR when this document was reviewed along with the bis documents we did not receive such observation.
>> 
>>> Also implementing just SHA-256 everywhere will make implementations simpler.
>> 
>> Wouldn’t this create an issue with older implementations?
> This is why I've asked whether there are any backward compatibility issues. If you already have older implementations, that you need to decide what you want to do about them. In the meantime, if you keep using SHA-1, you should probably explain this in the document. (E.g. "For backward compatibility with older implementations, ...")
>> Do you think that text could be adapted to RECOMMEND SHA-256 also expressing the concern that old implementation may not interoperate?
> I think making implementations use SHA-256 as a SHOULD requirement (unless you can use MUST, as you do in some cases listed above) would certainly help.

Should we make a difference between implementation and use?
I mean what about stating that new implementations MUST implement SHA-256, deployments SHOULD use SHA-256 unless older implementation with SHA-1 exist in the same deployment.

Does it make sense to you? 

>> 
>> Can you be more specific?
> I will come back to you on this one. 
>>> 2) In Section 7.7:
>>> 7.7.  Message Privacy
>>> 
>>>    DTLS [RFC9147] SHOULD be used to provide communication privacy and to
>>>    prevent eavesdropping, tampering, or message forgery to the messages
>>>    exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless
>>>    the OTK is encrypted in another way, e.g. using a pre-shared secret.
>>> 
>>> Is this talking abou OTK key wrapping? If yes, then this sounds a bit misleading, considering that AES-KEY-WRAP-128+HKDF-SHA256 is "MUST implement”.
>> 
>> But you can use the NULL-KEY-WRAP-128 and protect the message with DTLS, no?
> I think the answer depends on whether you want to generally encourage use of DTLS. If you do, perhaps the following would be clearer:
> 
AFAICT there was no intention tp encourage DTLS specifically. It was more about be clear that communications between strs and Map-Servers and Map-Resolvers must be protected.

Thanks

Ciao

L.