On Jan 3, 2021, at 10:44 PM, Martin Thomson <m...@lowentropy.net> wrote: > # Key Schedule > > The other thing I observe is the way that this slices up the exporter output. > This was something that old versions of TLS did, but TLS 1.3 did away with. > Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to. This could - > and should - do the same. All it means is having more exporter labels.
That's easy enough to change at this state. The question is what are those labels? And, we're getting very close to needing an implementation soon. RFC 8446 is over two years old. Web services have started serious migration to TLS 1.3. But we still don't even have a standard for EAP. I suggest that this is an issue. At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the major EAP peer / server implementations. This code is alpha, and not in any major release. But we need to decide fairly soon what we're doing, as testing and releases take time. The alternative is to dither around for another year or two, all the while relying on legacy TLS versions for 802.1X / WiFi authentication. i.e. packets which are trivially monitored by anyone with a WiFi card. > I appreciate that this uses exporters now rather than abusing the internal > PRF. That's good. The next step is to dispense with the intermediate values > (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS > exporter for each of the six values that the protocol requires. I also note > that the 0x0D value is used multiple times, unnecessarily, both as a context > strong to the exporter and as a prefix to the session ID. If EAP-TLS was the only TLS-based EAP method, I would agree with you. But it's not. Historically, each TLS-based EAP method uses it's own key derivations, using method-specific strings. This practice made implementations more difficult and error-prone. The use of 0x0D is to allow standard key derivations across TLS-based EAP methods. The other methods replaced the 0x0D byte with their own EAP type value. This practice greatly simplifies implementations. See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more information. Alan DeKok. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
