On Nov 14, 2018, at 9:04 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > Hi all, > > I think the draft is now in quite good shape. It would be good to get some > reviews.
A quick review, mostly NITs: Weaknesses found in previous versions of TLS, as well as new requirements for security, privacy, and reduced latency has led to I think this should be "... have led to ..." As stated in [RFC5216], the TLS cipher suite shall not be used to protect application data. This applies also for early application data. When EAP-TLS is used with TLS 1.3, early application data SHALL NOT be used. I'm not sure what section of RFC5216 says that the application data isn't protected. Perhaps this could be clarified? Section 2.1.3: .. higher. The two paragraphs below replaces the corresponding "replace", not "replaces" Section 2.1.5: Including ContentType and ProtocolVersion a single TLS record may be up to 16387 octets in length. Some EAP implementations and access networks may limit the number of EAP packet exchanges that can be handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes of client, server, and trust anchor certificates small and the length of the certificate chains short. The subsequent text talks about modifying the certificate formats (ECC vs RSA) in order to shrink the certs. It may be useful here to discuss other methods, too. e.g. adding full addresses, contact information, etc. into every certificate can increase the cert sizes by hundreds of bytes. Admins should investigate ways to identify certificates (especially intermediate ones) via something *other* than using the certificate as a database. Also, using many many intermediate certs should be discouraged. While the structure of the cert chain may mirror management structure in a company, technical limitations may mandate a different structure for certificate chains. In practice 2-3 intermediate certificates should be enough for most purposes. It may be better to have a wider "fan out" of certificate dependencies, instead of a deeper chain of certs. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
