Hi Michael, Hi draft authors, > I was surprised to get to the end of the document without any suggestions > about sending certificates by reference rather than value.
Having seen this statement from Michael I have reviewed the document. Two generic observations about the draft: 1) Many statements are made about deployments and no references are provided. To improve quality of the write-up I would strongly suggest to add such references, as you would have to do with an academic publication as well. 2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached Info was wrongly interpreted. They actually relate to the remark from Michael. > TLS certificates are often relatively large, and the certificate > chains are often long. I think this statement is in general incorrect. You could say that in deployment X certificates have size X and the chain is Y long. > Also, > from deployment experience, EAP peers typically have longer > certificate chains than servers. I would like a reference to be included here. Theoretically, it makes no sense to have a certificate chain for an EAP peer to have a longer certificate chain than a server given a EAP peer talks to one EAP server. In network access authentication it is not only about authentication but the most important part is authorization. Hence, you pretty much always have a one-to-one relationship between the EAP peer and the EAP server. There are no good reasons to have complex CA hierarchies here. > This is because EAP peers often > follow organizational hierarchies and tend to have many intermediate > certificates. Thus, EAP-TLS authentication usually involve > significantly more octets than when TLS is used as part of HTTPS. I think it would make sense to explain this organizational hierarchy aspect in a bit more detail. > The EAP fragment size > in typical deployments is just 1020 - 1500 octets. Reference for the 1500 octets. > For example, many EAP authenticator (access point) > implementations will drop an EAP session if it has not finished after > 40 - 50 round-trips. Is there a reference that could be included? > However, deployment > experience has shown that these jumbo frames are not always > implemented correctly. Add a reference here. > RADIUS can generally transport only about 4000 > octets of EAP in a single message. How was this number constructed? > A certificate chain (called a certification path in [RFC5280]) can > have 2 - 6 intermediate certificates between the end-entity > certificate and the trust anchor [RFC5280]. The PKIX reference here is misleading. I think you included it to refer to the terms but it sounds like the statement that the chain can have 2-6 intermediate CA certificates. I would add the terms to the terminology section and remove the PKIX reference here. I am also wondering what you are trying to say here with this sentence. Are you saying that you have seen deployments for network access authentication that have up to 6 intermediate CA certificates in the chain? > 3. Experience with Deployments > Most common access point implementations drop EAP sessions that do > not complete within 50 round-trips. This sentence is a repetition. > This means that if the chain is > larger than ~ 60 kB, EAP-TLS authentication cannot complete > successfully in most deployments. Regarding the 60 kB certificate chain: Should this be an indication to someone deploying the technology for access network authentication that something has gone wrong? Is this someone you have observed or is this just a theoretical statement? I hope it is the latter. 4.2.1. Pre-distributing and Omitting CA Certificates > When using TLS 1.3, all certificates that > specify a trust anchor known by the other endpoint may be omitted > (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, > only the self-signed certificate that specifies the root certificate > authority may be omitted (see Section 7.4.2 of [RFC5246] These sentences sound strange. In TLS (and probably other protocols) it makes no sense to distribute the trust anchors in the protocol itself (because then they wouldn't serve as an anchor for trust). It is my understanding that the TLS 1.3 spec does not require you to send intermediate CA certificates if they have been provisioned to the peer out-of-band already. The text in the TLS 1.2 spec is a bit fuzzy and calls out that the self-signed root certificate MAY be omitted but it does not say anything about omitting the other certs. >4.2.2. Caching Certificates There seems to be the misconception that TLS Cached Info requires a full exchange to work. It is the other way around: If you pre-distribute certificates upfront then there is no need to exchange the certs again. You could just send the fingerprints right away. A spec, however, has to also cover the bootstrapping problem. > 4.2.5. Using Fewer Intermediate Certificates > 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. I would make a stronger statement here. There is absolutely no reason for the certificate chain to mirror the organizational structure. I also don't understand why you would need a hierarchy of 4 intermediate CAs. Finally, at the end: Why did you omit - Client Certificate URLs - RFC 6066), which is also referenced in RFC 7925 and - cTLS (which also has a certificate compression scheme included). Theoretically, you could even list the ability to use alternative certificate format here. Then, you could list raw public keys or the CWT extension. Ciao Hannes PS: It is good to see John's name on a document that talks about TLS. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
