Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt

[Jouni Malinen <[e-mail]>]

On Thu, May 31, 2018 at 2:45 PM, John Mattsson <[e-mail]>
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