Hi Elwyn, Thank you for the careful review. We have updated the draft based on your feedback. Here is the diff for you convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-06. See our responses in-line. --Mohit On 10/24/20 1:44 PM, Elwyn Davies via Datatracker wrote: > 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. Most of the normative references are to already published RFCs. There is only one normative reference to a draft which will also hopefully move forward soon. You are right that there are many informational references to work in progress. But this is what the working group participants wanted. For example, Hannes suggested to add references to new TLS certificate types and certificate compression with CBOR: https://mailarchive.ietf.org/arch/msg/emu/cIVEGF6eLCvrdCqkA5Zzjxor9vs/. I think it can be valuable for a reader to have concrete examples of work in progress. > > 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. Now there is only one SHOULD NOT. I'll let the IESG deliberate if they want us to change to "should not" instead. But I think it is an important operational guideline and as Alan DeKok noted, administrators should really ensure that certificate chains don't contain more than 2-4 intermediate certificates. > > Abstract: Need to expand EAP-TLS and EAP on first occurrence. Done. > > s1, end of para 2: Suggest s/involves significantly more octets/involves > exchange of significantly more octets/ Done. > > s2, definition of EAP server: Where would a reader find a definition of > "backend authentication"? Uncle Google was singularly unhelpful. The text does say "Readers are expected to be familiar with the terms and concepts used in EAP [RFC3748]". The term backend authentication server is defined there: https://tools.ietf.org/html/rfc3748#section-1.2. In this document, we only define the terms that are used frequently. And backend authentication server wasn't one of them. > > s3, last para: clarify the meaning of kB: suggest s/~ 60kB/approximately 60 > kbytes/ (I assume). Done. > > 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 Thank you. I have used your text with slight modifications. > > s4.1.1, para 1: s/is as follows/are as follows/ Done. > > s4.1.1, para 2 (1st bullet): s/Object Identifiers (OIDs) is ASN.1/The Object > Identifier (OID) is an ASN.1/ Done. > > s4.1.1, para 3 (1st bullet): Need to expand DER. Also useful to add reference > to RFC5280 after X.509. Done. > > s4.1.1, para 4 (1st sub-bullet n 1st bullet) 'vs' needs to be expanded - either > 'versus' or (Better) 'as against'. Done. > > 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/. No change. See above. > > s4.2.2, para 1: s/useful when, for example, when/useful when, for example,/ Done. > > s4.2.4: s/can define dictionary of/can define a dictionary of/ Done. > > s4.2.5: s/For a client that has all intermediates,/For a client that has all > intermediate certificates in the certificate chain/ Done. > > s4.2.5: The second sentence of this section needs to be rewritten as if > draft-thomson-tls-sic is already an RFC. Could you give the RFC number. As far as I can tell, it is an expired personal submission but I could be wrong: https://datatracker.ietf.org/doc/draft-thomson-tls-sic/ > > 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. No change. See above. > > 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 Updated with slight modifications. > > 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. Done. > > > > _______________________________________________ > Emu mailing list > Emu@xxxxxxxx > https://www.ietf.org/mailman/listinfo/emu -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
