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

[Barry Leiba via Datatracker]

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!



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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
>
> .
>
> 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 

[Emu] I-D Action: draft-ietf-emu-eaptlscert-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Handling Large Certificates and Long Certificate 
Chains in TLS-based EAP Methods
Authors : Mohit Sethi
  John Mattsson
  Sean Turner
Filename: draft-ietf-emu-eaptlscert-06.txt
Pages   : 14
Date: 2020-10-28

Abstract:
   The Extensible Authentication Protocol (EAP), defined in RFC3748,
   provides a standard mechanism for support of multiple authentication
   methods.  EAP-Transport Layer Security (EAP-TLS) and other TLS-based
   EAP methods are widely deployed and used for network access
   authentication.  Large certificates and long certificate chains
   combined with authenticators that drop an EAP session after only 40 -
   50 round-trips is a major deployment problem.  This document looks at
   the this problem in detail and describes the potential solutions
   available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-06
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu