On Thu, May 31, 2018 at 2:45 PM, John Mattsson <john.matts...@ericsson.com> wrote:
> Except editorials, the main change is that the Exporter labels has been > changes to conform with RFC 5705 and that the labels are now to be > registered by IANA as they should be. > > Review and comments are very welcome. Preferable so that they can be > included in a -01 version before Montreal. > Based on implementation experiment of this (or well, the previous draft, so with the old labels), the most inconvenient part of this design was the way the session resumption is handled in TLS v1.3. When that is mapped to EAP-TLS in the way it is in this draft, the peer has no idea whether the NewSessionTicket is delivered after ClientFinished. In other words, the next message in the sequence could be either continuation of EAP-TLS method or EAP-Success. This means that the peer cannot use methodState=DONE, decision=UNCOND_SUCC per RFC 4137 state machine whenever using TLS v1.3 (while being able to continue to use that combination with TLS v1.0, v1.1, and v1.2). Instead, for TLS v1.3, methodState=MAY_CONT, decision=COND_SUCC needs to be used. While this may not sound very critical, it was a bit inconvenient to have make that behavior conditional on the TLS version. Would there be any way of avoiding this uncertainty about the next message on the client side within the EAP-TLS method itself? If not, I might as well as bring up another comment regarding the extra round trip from this NewSessionTicket delivery. That does not look very efficient. If we would not care about layering between the EAP method and EAP peer/server implementation, NewSessionTicket could actually be piggybacked on top of the EAP-Success message.. Sure, that would require a change in the EAP-Success definition, but this would remove this undesired uncertainty about the next message in the sequence and would get rid of one extra roundtrip in the exchange which could be a significant reduction in overall latency for the handshake. Having to change the MSK/EMSK derivation just for the sake of getting a new label string into use based on the TLS version is also a bit inconvenient. This is obviously assuming that the previous implementation was already using TLS-Exporter interface. In general, it would have been nicer if existing EAP-TLS implementations would work simply by updating the TLS implementation from v1.2 to v1.3. Anyway, if any one of these change is going to be needed in the end, the EAP method implementation will need to be made aware of the negotiated TLS version and other changes are coming with somewhat reduced implementation complexity. - Jouni
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
