On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote: > > I would instead either prohibit the use of application data outright or say > that it carries no semantics unless otherwise negotiated. The current design > has the effect of rendering application data unusable, so perhaps the former > is best.
The "rendering application data unusable" bit is something that bothered me a lot as well. While banning application data is okay for EAP-TLS itself (AIUI), the document implies that other TLS-based EAP mechanisms do need to convey application data, and I think that the responsible thing to do is ensure that the machinery we use here would be compatible with those other EAP mechanisms with no, or only minimal, changes. > # 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. > > 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. I think Alan explained the dual purpose of the Type-Code here. (I myself had missed the connection of where the 0x0d value came from, and a reference for that seems like it would be helpful, as setting up this machinery for reuse by other mechanisms in a way that provides key separation.) -Ben _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
