Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods
Note: This ballot was opened for revision 06 and is now closed.
Benjamin Kaduk Yes
Comment (2020-11-03 for -06)
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.
Erik Kline Yes
Roman Danyliw Yes
Éric Vyncke Yes
Comment (2020-11-05 for -06)
Ending this round of IESG evaluation reviews with this document. Good choice as it is easy to read, addresses a real problem, and provides a lot of common sense/sensible suggestions. Like noted by Barry and others, I think that this document could aim for a 'higher grade' status (BCP for example); OTOH, some sections such as 4.2.3 propose protocol extensions that won't fit in a BCP or PS. Regards -éric
Alvaro Retana No Objection
Murray Kucherawy No Objection
Comment (2020-11-04 for -06)
Thanks for this. I second Robert's comments on this being easy to read and enlightening. I note that the only use of BCP 14 language is a single SHOULD NOT in Section 4.1.3. You might be able to simplify this away with some light editing.
Robert Wilton No Objection
Comment (2020-11-02 for -06)
Thank you for this document. I found it informative, easy to read, and enlightening on a problem that I wasn't aware of. I agree with Barry comment that it would be useful to talk about whether this should be a BCP or Informational. Regards, Rob
(Barry Leiba; former steering group member) No Objection
No Objection (2020-10-28 for -06)
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!
(Deborah Brungard; former steering group member) No Objection
( for -06)