Subject: [Emu] Genart last call review of draft-ietf-emu-eaptlscert-05

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Sat, 24 Oct 2020 03:44:18 -0700

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.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 28 Oct 2020 10:45:54 +0000

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

> 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.
> from the  intended infromational status.  The RFC 2119 etc boilerplate in s2
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.
> exchange of significantly more octets/
Done.
> "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
Done.
> 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.
> Identifier (OID) is an ASN.1/
Done.
> s4.1.1, para 3 (1st bullet): Need to expand DER. Also useful to add reference
Done.
> 'versus' or (Better) 'as against'.
Done.
> 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.
> intermediate certificates in the certificate chain/
Done.
> 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/
> explicit examples but exhorting implementors and operatirs to consider relevant
No change. See above.
> denial-of-service attacks. ENDS
Updated with slight modifications.
> necessary, adding the two points from the first sentences as reminders rather
Done.
>
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu