[Gen-art] Genart last call review of draft-ietf-emu-eaptlscert-05

[Elwyn Davies via Datatracker <[e-mail]>]

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.