Hi Valery, Bob, Many thanks to Valery for the review. (focusing on point 3) Please see inline. Cheers, Med > -----Message d'origine----- > De : Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx> > Envoyé : mercredi 30 mars 2022 16:47 > À : Valery Smyslov <valery@xxxxxxxxxxx>; secdir@xxxxxxxx > Cc : draft-ietf-drip-arch.all@xxxxxxxx; last-call@xxxxxxxx; tm- > rid@xxxxxxxx > Objet : Re: Secdir last call review of draft-ietf-drip-arch-22 > > I am taking a quick response here, and will have to go over it more > closely for a second pass. > > On 3/30/22 09:51, Valery Smyslov via Datatracker wrote: > > Reviewer: Valery Smyslov > > Review result: Has Issues > > > > The topic of the draft is complex and involves many fields which I'm > > not expert of. The overall architecture looks secure, however it's > > difficult for me to analyse all the details. Nevertheless, it seems to > > me that there are some security issues with the draft. > > > > > 3. Section 9. > > > > The size of the public key hash in the HHIT is also of concern. > It > > is well within current server array technology to compute another > key > > pair that hashes to the same HHIT. > > > > If I understand the draft correctly, the size of public key hash is 20 > > or 19 octets (Section 3.1). > > The architecture document does not detail the format of an HHIT. It > turns out that in draft-ietf-drip-rid, the hash size is 64 bits so this > attack is real and details about it are in the Security Considerations > of that draft. Perhaps say: > > The size of the public key hash in the HHIT (64 bits) is also of concern > > ? Do we need to reference ietf-drip-rid? We really do not want to do > that is it creates delaying dependencies. [Med] The initial point was to record the potential security consideration that should be further examined in the solution spec. I'm not convinced we need to call out solution-specific details (e.g., 64 bits) here or call out ietf-drip-rid. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
