[Emu] AD review of draft-ietf-emu-eap-tls13-09

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-emu-eap-tls13-09.  Thanks for the work on modernizing existing guidance to cover TLS 1.3.

Two high level things caught my attention:

** The abstract, introduction and title suggested to me that this document is only about TLS 1.3+EAP.  If I wasn't using TLS 1.3, then there is nothing here of interest.  However, there appears to be text here that updates non-TLS 1.3 guidance.  I recommend being clear about that up front (in the abstract and introduction).

** Section 2.1 explicitly says that "[t]his document only lists additional and different requirements, restrictions, and processing compared to [RFC8446] and [RFC5216]."  The text tries to match section headers names with [RFC5216] (which is helpful).  However, I didn't always follow the "updates" without some searching.  Editorially, given a particular description of behavior, I recommend being clearer by consistently making explicit reference to a particular section in RFC5216 that is being updated. 

More details on the above observations and others below:

(1) Can you please check the boiler plate language, idnits is complaining is as follows:
  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
     (Using the creation date from RFC5216, updated by this document, for
     RFC5378 checks: 2007-07-01)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

(2) Section 1.  Editorial.  Instead of something working "perfectly", maybe just "supports"
OLD
   EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346],
   but works perfectly also with TLS 1.2 [RFC5246].   

NEW
EAP-TLS [RFC5216] explicitly references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], but it also supports TLS 1.2 [RFC5246].   

(3) Section 1.  Editorial.  "Easy" might be relative.

OLD
   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and easy with OCSP stapling,

NEW
Privacy is mandatory and achieved without any additional round-trips,   revocation checking is mandatory and simplified with OCSP stapling,

(3) Section 2.1.1.  What is the relationship between this section and NAI guidance in RFC5216 Section 2.1.4?  Is it that anonymous NAIs are RECOMMENDED for TLS 1.3, but stay a MAY in old EAP-TLS?

(4) Section 2.1.3.  Editorial.  To prevent the reader from having to line up which paragraphs are being replaced in Section 2.1.3 of [RFC5216], I would recommend citing the old text and showing how this text replaces it.  Additionally, since RFC5216 lists the peer guidance before the server, I'd recommend reversing the order.  For example:

Original TLS guidance from RFC5216:
If the peer authenticates successfully, the EAP server MUST respond
   with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in
   the case of a new TLS session, one or more TLS records containing TLS
   change_cipher_spec and finished handshake messages.  The latter
   contains the EAP server's authentication response to the peer.  The
   peer will then verify the finished message in order to authenticate
   the EAP server.
...
   If the EAP server authenticates successfully, the peer MUST send an
   EAP-Response packet of EAP-Type=EAP-TLS, and no data.  The EAP Server
   then MUST respond with an EAP-Success message.

TLS 1.3 guidance:
[insert new language in the draft now]

(5) Section 2.1.5.  Is Figure 6 supposed to be read as being inclusive of all TLS messages?  The figure doesn't contain TLS CertificateRequest, TLS Certificate, or TLS CertificateVerify.  It wouldn't be germane to what the figure is trying to demonstrate but the examples in prior sections are "complete".

(6) Section 2.1.6.  The text here seems right to describe TLS 1.3 behavior.  Recommend being clearer on which behavior this is replacing in TLS-EAP (i.e., explicitly citing a given section in RFC5216; is it Section 2.1.2?)

(7) Section 2.1.7.  The text here seems right to describe TLS 1.3 behavior.  Recommend being clearer on which behavior this is replacing in TLS EAP (i.e., explicitly citing a given section in RFC5216)

(8) Section 2.1.7.  Per "When NAI reuse can be done without privacy implications", is there any guidance that can be provided on where there would be a privacy issue?

(9) Section 2.1.9.  The text here seems right to describe TLS 1.3 behavior.  Recommend being clearer on which behavior this is replacing in TLS EAP (i.e., explicitly citing a given section in RFC5216, is it Section 2.1.5?)

(10) Section 5.1. Editorial.  Wrong section reference. s/Section 4.1. of [RFC5216]/Section 5.1 of [RFC5216]/

(11) Section 5.1.  Per "better confidentiality" in [2], this seems imprecise

(12) Section 5.4.  Per "While certificates often have a long validity period spanning several years, there are ...", as this is changing perhaps just say "While certificates may have long validity periods, there are ..."

(13) Section 5.5.  Recommend that this section read "No updates to Section 5.5 of [RFC5216]"

(14) Section 5.6.  The guidance in this section does appear to be TLS 1.3 specific.  If it isn't, it should be noted as such.

(15) Section 5.7.  Per "Since accounting must be tied to an authenticated identity ...", is there is a reason not to use a normative MUST here?  Especially since later a normative RECOMMENDED is used for "It is RECOMMENDED that authorization, accounting and policy decisions are reevaluated based on information given in resumptions".

(16) Section 5.8.  Editorial. Per "[RFC6973] suggests that the privacy considerations of IETF protocols be documented", it isn't clear to me what this sentence is adding.

(17) Section 5.8.  Editorial.  s/TLS 1.3 offers much better privacy than .../TLS 1.3 offers better privacy properties than .../

(18) Section 5.8.  Editorial. Per "If privacy-friendly identifiers with encrypted usernames need to be generated with care", as written, this is a only sentence fragment.

(19) Section 5.8.  Per "An EAP peer with a policy allowing communication with EAP servers supporting only TLS 1.2 without privacy  and with a static RSA key exchange is vulnerable to disclosure of the peer username", the "without privacy" would benefit from being more precisely stated.

(20) Section 5.9.  Editorial. Per "As required by [RFC7258] ...", I'm not sure what this sentence adds.

(21) Section 5.9.  Could you contextualize this "widespread surveillance of users " more specifically within the EAP context.

Regards,
Roman