Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-emu-eaptlscert-05 Reviewer: Elwyn Davies Review Date: 2020-10-24 IETF LC End Date: 2020-10-28 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. There are quite a number of references to associated work that is still in progress as drafts. Whilst this is unlikely to compromise the content of this work, it will potentially delay its publication. In particular I have suggested rewriting s4.2.7 to omit more speculative references to incomplete work in favour of a general recommendation to make use of relevant new proposals as they become available. Major Issues: None Minor Issues: None Nits and Editoral Issues: General: RFC 2119 key words: In the document there are two MUSTs and a SHOULD NOT none of which are appropriate usages in my opinion (see notes below), aside from the intended infromational status. The RFC 2119 etc boilerplate in s2 could be omitted. Abstract: Need to expand EAP-TLS and EAP on first occurrence. s1, end of para 2: Suggest s/involves significantly more octets/involves exchange of significantly more octets/ s2, definition of EAP server: Where would a reader find a definition of "backend authentication"? Uncle Google was singularly unhelpful. s3, last para: clarify the meaning of kB: suggest s/~ 60kB/approximately 60 kbytes/ (I assume). s4: The usage of the form " we look/discuss/etc." typically used in academic papers is not appropriate for standards documents. Section 4 needs to be redrafted to eliminate this usage. The following may be appropriate: OLD: This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP- TLS authentication. In Section 4.1 we look at recommendations that require an update of the certificates or certificate chains that are used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. We also provide some guidelines when issuing certificates for use with EAP-TLS. In Section 4.2 we look at recommendations that rely on updates to the EAP-TLS implementations which can be deployed with existing certificates. In Section 4.3 we shortly discuss the solution to update or reconfigure authenticator which can be deployed without changes to existing certificates or EAP-TLS code. NEW: This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP- TLS authentication. Section 4.1 considers recommendations that require an update of the certificates or certificate chains that are used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. The section also provides some guidelines that ahould be followed when issuing certificates for use with EAP-TLS. Section 4.2 considers recommendations that rely on updates to the EAP-TLS implementations which can be deployed with existing certificates. Finally Section 4.3 briefly discusses what could be done to update or reconfigure authenticators where it is infeasible to replace deployed components giving a solution can be deployed without changes to existing certificates or EAP-TLS code. ENDS s4.1.1, para 1: s/is as follows/are as follows/ s4.1.1, para 2 (1st bullet): s/Object Identifiers (OIDs) is ASN.1/The Object Identifier (OID) is an ASN.1/ s4.1.1, para 3 (1st bullet): Need to expand DER. Also useful to add reference to RFC5280 after X.509. s4.1.1, para 4 (1st sub-bullet n 1st bullet) 'vs' needs to be expanded - either 'versus' or (Better) 'as against'. s4.1.3, para 1: The use of capitalized SHOULD NOT here is, I think, inappropriate. This is an operational recommendation rather than a protocol requirement, so s/SHOULD NOT/should not/. s4.2.2, para 1: s/useful when, for example, when/useful when, for example,/ s4.2.4: s/can define dictionary of/can define a dictionary of/ s4.2.5: s/For a client that has all intermediates,/For a client that has all intermediate certificates in the certificate chain/ s4.2.5: The second sentence of this section needs to be rewritten as if draft-thomson-tls-sic is already an RFC. s4.2.7: This section is not 'future proof'. It should be rewritten omitting the explicit examples but exhorting implementors and operatirs to consider relevant future developments. s4.3, para 1: The second and third sentences don't read well.Suggest: OLD: Another second reason is that unlimited communication from an unauthenticated device as EAP could otherwise be use for bulk data transfer. A third reason is to prevent denial-of-service attacks. NEW: Other reasons include that unlimited communication from an unauthenticated device using EAP could provide a channel for inappropriate bulk data transfer, and that communication could facilitate denial-of-service attacks. ENDS s6, para 2: The MUSTs look as if they are imposing requirements on draft-ietf-tls-certificate-compression. I am sure that the draft would be effectively saying these things anyway (if not, why not?) Also the first sentence appears to be truncated - it doesn't make any sense as it stands. I suggest rewriting the paragraph with the third sentence first, and, if really necessary, adding the two points from the first sentences as reminders rather than MUSTs. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
