Subject: [Emu] Benjamin Kaduk's Yes on draft-ietf-emu-eaptlscert-06: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 23:04:40 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eaptlscert-06: Yes

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

Thank you for responding to the secdir review and thanks to Stefan
Santesson for the review -- the changes staged in github are a
significant improvement!

Though I am balloting Yes, please see my remarks about
draft-thomson-tls-sic in the comments on Section 4.2.5 -- it is expired
and was not adopted by the TLS WG and we should not imply that it is a
current work item there.

I also made a pull request at
https://github.com/emu-wg/eaptls-longcert/pull/4 with a few editorial
fixes/suggestions.

Section 3

   o  Multiple user groups in the certificate.

What are "user groups" in a certificate?

   A certificate chain (called a certification path in [RFC5280]) can
   commonly have 2 - 6 intermediate certificates between the end-entity
   certificate and the trust anchor.

The '2' here is surprising to me; my understanding was that having just
1 intermediate was quite common, especially on the web.

   Many access point implementations drop EAP sessions that do not
   complete within 50 round-trips.  This means that if the chain is

Earlier we said "40 - 50"; we should probably be consistent about it.

Section 4.1

   1.3 [RFC8446] requires implementations to support ECC.  New cipher
   suites that use ECC are also specified for TLS 1.2 [RFC5289].  Using

nit: RFC 8422 might be a better reference than 5289, here.

Section 4.1.3

   The EAP peer certificate chain does not have to mirror the
   organizational hierarchy.  For successful EAP-TLS authentication,
   certificate chains SHOULD NOT contain more than 2-4 intermediate
   certificates.

This seems equivalent to the shorter "SHOULD NOT contain more than 4
intermediate certificates".

Section 4.2

   by updating the underlying TLS or EAP-TLS implementation.  Note that
   in many cases the new feature may already be implemented in the
   underlying library and simply needs to be taken into use.

Hmm, "many" might be a stretch, given that the majority of the
mechanisms we refer to are still at the internet-draft stage.

Section 4.2.2

   possible.  An option in such a scenario would be to cache validated
   certificate chains even if the EAP-TLS exchange fails, but this is
   currently not allowed according to [RFC7924].

This is arguably not a strict requirement in 7924; the text in question
looks to be:

% Clients MUST ensure that they only cache information from legitimate
% sources.  For example, when the client populates the cache from a TLS
% exchange, then it must only cache information after the successful
% completion of a TLS exchange to ensure that an attacker does not
% inject incorrect information into the cache.  Failure to do so allows
% for man-in-the-middle attacks.

The normative MUST is for "legitimate sources", and "only after
successful TLS exchange" uses the lowercase MUST.  Of course, 7924
predates 8174, so it's not fully clear-cut, but there may be some ground
to stand on for caching validated certificate chains prior to a
completed TLS handshake (provided that other validation is performed
properly).

Section 4.2.4

   "known certificates".  Thus, cTLS can provide another mechanism for
   EAP-TLS deployments to reduce the size of messages and avoid
   excessive fragmentation.

cTLS is at a fairly early stage; it might be better to say "could
provide" rather than "can provide".

Section 4.2.5

   handshake increases the size of the handshake unnecessarily.  The TLS
   working group is working on an extension for TLS 1.3
   [I-D.thomson-tls-sic] that allows a TLS client that has access to the

It is not accurate or appropriate to say that "the TLS working group is
working on" an individual I-D that is not adopted by the WG.
Suppressing intermediate certificates might be more appopriate in the
"new certificate types and compression algorithms" section, that seems
to be the home for most of the still-speculative stuff.

Section 4.2.6

   certificate chains.  Deployments can consider their use as long as an
   appropriate out-of-band mechanism for binding public keys with
   identifiers is in place.

It is also important to consider revocation and key rotation when
considering the use of raw public keys.

Section 6

We probably want a general disclaimer that the security considerations
of the referenced documents apply, in addition to whichever pieces we
cherry-pick for specific mention.  (In light of my previous comment
about draft-thomson-tls-sic, we may want to not use that as one of the
things to cherry-pick for special mention.)

We might also mention that various ways to avoid sending certificates
over the wire do not obviate the endpoints' responsibility to check
revocation information.

Similarly, efforts to trim certificate size should not remove extensions
or other attributes that are necessary for secure operation (though that
is perhaps a bit banal to actually say).

Section 7.2

I think RFC 8446 needs to be a normative reference.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 4 Nov 2020 16:41:07 +0000

Hi Ben,

This should hopefully address your feedback: 
https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8

Answers in-line.

--Mohit

> https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/
The text now says: It can contain multiple organization fields to 
reflect the multiple group memberships of a user (in a client certificate).
> 1 intermediate was quite common, especially on the web.
Added that certificate chains in 'EAP-TLS' can have 2-6 intermediate 
certificates.
> Earlier we said "40 - 50"; we should probably be consistent about it.
Fixed.
> nit: RFC 8422 might be a better reference than 5289, here.
Updated.
> intermediate certificates".
Changed to 4.
> mechanisms we refer to are still at the internet-draft stage.
Changed to "some"
> completed TLS handshake (provided that other validation is performed
Updated text says " An option in such a scenario would be to cache 
validated certificate chains even if the EAP-TLS exchange fails, but 
such caching is currently not specified in [RFC7924]."
> provide" rather than "can provide".
Changed to "could provide".
> to be the home for most of the still-speculative stuff.
Yep. Good point. Removed the text "The TLS working group is working...". 
However, I haven't moved this to the "new certificate types and 
compression algorithms" section.
> considering the use of raw public keys.
Added: "Naturally, deployments will also need to consider the challenges 
of revocation and key rotation with the use of raw public keys."
> is perhaps a bit banal to actually say).
Removed the text of draft-thomson-tls-sic and added "Specific security 
considerations of the referenced documents apply when they are taken 
into use."
> I think RFC 8446 needs to be a normative reference.

Now it is normative.

Happy to edit further as needed!

--Mohit

>
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Nov 2020 17:04:36 -0800

> https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8

Thanks Mohit!

I left one wording tweak (s/defines/proposes/) on the github commit, but
otherwise this all sounds fine to me.

-Ben