Subject: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 28 Oct 2020 12:21:14 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-emu-eaptlscert-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this; it will be useful to have this issue fixed.

There’s something I’d like to discuss, but without making it a blocking DISCUSS:
While I understand the reason for putting this forward as Informational, it
does strike me more as a Standards Track Applicability Statement.  BCP 9 says
(in RFC 2026 Section 3.2):

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.

Reading the rest of Section 3.2 as well, I think that it fits exactly what
you’re doing with this document: the document is saying that there’s an
interoperability problem with large certs and long chains, and here are things
to do in order to make that work.  Let’s please have a brief discussion about
whether this should instead be published at Proposed Standard as an AS.

—————

Below are some nits that I hope you’ll consider, but there’s no need to respond
in detail here; please do as you think best.

— Section 1 —

   vendor specific EAP methods.

Need a hyphen in “vendor-specific”.

   EAP-TLS
   deployments typically authenticates both the EAP peer and the EAP

Make it “authenticate”.

   Section 3.1 of [RFC3748] states that EAP implementations can assume a
   MTU of at least 1020 octets from lower layers.

Unless you have a way of pronouncing “MTU” that I don’t, make it “an MTU”.

   Such fragmentation can not only negatively
   affect the latency, but also results in other challenges.

The “can” is misplaced; make it “not only can affect”.

— Section 2 —

   The document additionally uses the terms trust anchor and
   certification path defined in [RFC5280].

I would put “trust anchor” and “certification path” in quotes here.

— Section 3 —

   Certificate sizes can however be large

Commas are needed both before and after “however”.  Also, the list talks about
a singular “certificate”, so the lead-in should match that (and you don’t need
to say that a *size* can be large): “A certificate can, however, be large for a
number of reasons:”

The list is also not parallel (the third item, in particular, is not like the
others).  I would make the whole list be complete sentences, like this,
referring to “a certificate” in the lead-in:

NEW
   o  It can have a long Subject Alternative Name field.

   o  It can have long Public Key and Signature fields.

   o  It can contain multiple object identifiers (OID) that indicate the
      permitted uses of the certificate as noted in Section 5.3 of
      [RFC5216].  Most implementations verify the presence of these OIDs
      for successful authentication.

   o  It can contain multiple user groups.
END

— Section 4.1 —

Throughout this paragraph you refer to “size of public keys” and “size of
digital signatures”.  It’s a really nitty nit, but I would make these all
singular, because we’re really talking about the size of an individual public
key or digital signature, not the size of a collection of them.

   authentication which can alleviate the problem of authenticators

There needs to be a comma before “which”.

   ECC based cipher suites with existing code can significantly

Hyphenate “ECC-based”.

— Section 4.1.1 —

   OIDs are used lavishly in X.509 certificates

I like it: “lavishly” is not a word we often see in RFCs.  :-)

      DNs
      used in the issuer and subject fields as well as numerous
      extensions.

This is not a complete sentence; please fix that (I think you’re just missing
“are” after “DNs”).

   CN=Coolest IoT Gadget Ever

Oh!  I want that!

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 30 Oct 2020 08:12:07 +0000

Hi Barry,

Thank you for the careful review. I have updated the draft in github 
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your 
convenience: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt. 
I will wait for all the comments to come in before submitting a new version.

Regarding your comment of informational vs. applicability statement: I 
am not opposed to the idea. I am happy to follow whatever the IESG 
recommends.

--Mohit

On 10/28/20 9:21 PM, Barry Leiba via Datatracker wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Oct 2020 10:16:57 -0400

Thanks, Mohit, for addressing my comments... and I'm glad you also
added text about the effect of quantum-safe algorithms on key and
signature sizes.

On the document status issue, I'd like to hear what other working
group participants think, and also what Roman's thoughts are.

Barry