Thanks Valery, we will incorporate fixes for these along with fixes for Tirumal’s comments into rev 9 ASAP.
From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Thursday, 16 May 2024 at 14:38 To: Valery Smyslov <s...@elvis.ru> Cc: draft-ietf-opsawg-tacacs-tl...@ietf.org <draft-ietf-opsawg-tacacs-tl...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org> Subject: RE: Request to review draft-ietf-opsawg-tacacs-tls13 Hi Valery, (ccing the OPSAWG to have a public record of your excellent review). All good points. Many thanks. I trust the authors will follow up SOON. Please see some comments from my side. Cheers, Med De : Valery Smyslov <s...@elvis.ru> Envoyé : jeudi 16 mai 2024 15:24 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : draft-ietf-opsawg-tacacs-tl...@ietf.org Objet : RE: Request to review draft-ietf-opsawg-tacacs-tls13 Hi Med, all, I finally reviewed the draft. I think that the document is in a good shape. It’s understandable and easy to read. Some polishing is needed though. I also think that it’s worth to circulate this document in the UTA WG asking for reviews. [Med] We need to make sure UTA WG is cced in the WGLC. There are many much more knowledgeable people than I am. Issues (both technical and editorial). 1. Perhaps the name of the document should be “TACACS+ over TLS 1.3” or “Using TLS 1.3 to secure TACACS+”? 2. Section 3.2 mentions “Single Connection Mode” which is not defined in this draft. Perhaps an addition of a reference to RFC 8907 Section 4.3 would be helpful for those readers (like me), who are not familiar with TACACS+? 3. Section 3.2: in the sentence “If Single Connection Mode has been negotiated, it might remain open after a successful session, until an error or an inactivity timeout occurs.” perhaps s/session/session conclusion ? 4. Section 3.2.1: I think that the proper name of the section should be “Cipher Suites Requirements” 5. Section 3.2.1: actually referencing Section 4.3 of RFC9325 for cipher suite recommendations is misleading, since that section contains no recommendations and refers to the RFC 8446 Section 9.1 instead, which is already mentioned above. 6. Section 3.2.2: The text “Unless disabled by configuration, a peer MUST disconnect any peer that presents an invalid TLS Certificate.” in my reading implies that peer is first connected and then disconnected if it presents an invalid TLS Certificate. How can this happen? TLS connection just should not succeed in this case in my opinion… Am I missing something? 7. Section 3.2.2: referencing RFC 7250 is a bit problematic, since it defines using RPKs for TLS 1.2 only (and thus contains TLS 1.2 specific information). RPKs is also supported in TLS 1.3, but referencing this support is not an easy task – there is no dedicated section in RFC 8446… I don’t have any good proposals here, perhaps just add reference to 8446 in addition to 7250. 8. Section 3.2.2: referencing RFC 8773 for PSK is incorrect. Using sole PSK is defined in RFC 8446, while RFC 8773 defines using PSK+Certificate. 9. Section 5.1: Perhaps it’s worth to replace the reference to RFC 9325 here with the reference to BCP 195. Thus all its future versions will be accounted. 10. Section 5.1.1. The last para is confusing. First, TLS 1.3 does not have cipher suites with NULL algorithms. Then, server authentication is always mandatory in TLS 1.3 and this document requires mutual authentication. So, it is not clear under what conditions this recommendation can be applied. 11. Section 5.1.2: A naïve question – why servers MUST abruptly disconnect clients that send 0-RTT data instead of ignoring this data? [Med] The authors made that change to address a comment for the secdir review. Since 0-RTT is not allowed (no profile is defined), I think the point was to be strict when clients don’t follow the MUST NOT early data. 12. Section 5.1.3: RFC 7525 is obsoleted by RFC 9325, why it is referenced (along with 9325)? 13. Section 5.1.5: Perhaps it’s worth to provide an informative reference to draft-ietf-tls-esni. [Med] Beside the reference, I’m not sure ESNI is actually needed for TACACS+, but this is a point to clarify as well. 14. Sections 5.1.4, 5.1.5, 5.2, 5.3, 6.2: I think that RFC 2119 language should be used very carefully here. In particular, requirements to operators and implementations are not relevant to the protocol behavior. I think that low-case words “must”, “should”, “may” etc. should be used instead in these cases. 15. Section 6: Shouldn’t the name of the section be “Operational Considerations”? Regards, Valery. Re-, Thank you for the positive feedback. Mid may is OK. Cheers, Med De : Valery Smyslov <s...@elvis.ru<mailto:s...@elvis.ru>> Envoyé : jeudi 25 avril 2024 13:05 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : draft-ietf-opsawg-tacacs-tl...@ietf.org<mailto:draft-ietf-opsawg-tacacs-tl...@ietf.org> Objet : RE: Request to review draft-ietf-opsawg-tacacs-tls13 Hi Med, I'm on vacation now till the end of April and then we'll have here few long holidays (1st May, Victory Day), so I think I'll be able to review the draft by the mid of May. Is it OK? Regards, Valery. Hi Valery, I hope you are doing well. Can you please review this document (draft-ietf-opsawg-tacacs-tls13-07 - TACACS+ TLS 1.3<https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/>) and share comments/suggestions you may have? The WG tried to follow the existing recos out there (including UTA’s BCPs). As a Shepherd, I’d like to check that we are OK on that front. Unless you have objections, I will forward your feedback to the OPSAWG list. Thank you. Cheers, Med ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
