On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote: > [Joe] I'm not sure I remember correctly, but I think the commitment > message was to make the integration with EAP statement machine cleaner > and perhaps to future proof against additional messages sent after the > handshake. I tend to agree that the value is low in the current > situation (It is a deviation from RFC 5216). Given all the discussion > this message has caused I'm tempted to agree that we should just remove > it (or make it "optional" in case implementations already do this). > There may need to be some text in the draft that says the > NewSessionTicketMessage must be sent in the same flight as the finished > message. I'd like to understand if there is an implementation > consideration that requires the commitment message.
That might be possible, but many implementations won't be happy with that requirement. Some implementations, particularly those that use tickets rather than server state, can't send NewSessionTicket until they have the client Certificate. > > # 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. > > > [Joe] I can see your point, but I don't think the way the keys are > derived is wrong and don't really see the need to change it at this > point. Depends on what you consider "wrong". In TLS, we did this so that you could exercise good key hygiene. If you are backing this with PKCS#11, then you might prefer not to be exporting the value of keys just so that you can do some slicing and then re-import the same value. I see no reason that EAP would be above this. > [Joe] yes, however I think the agreement during the chartering was that it > would > just update and not obsolete RFC 5216. Given the magnitude of the change, I don't see what this gains you other than a document that is really hard to use. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
