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

From: John Mattsson <[email-masked]>
Date: Thu, 31 May 2018 11:45:24 +0000

A diff from the last version can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-mattsson-eap-tls13-02.txt&url2=https://www.ietf.org/id/draft-ietf-emu-eap-tls13-00.txt

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. 

Things that has been discussed is:
 - Move non-TLS 1.3 details on fragmentation to another document
 - Give some more guidelines and information about privacy interop.

Cheers,
John

On 2018-05-30, 18:43, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-ietf-emu-eap-tls13-00.txt
    has been successfully submitted by Mohit Sethi and posted to the
    IETF repository.
    
    Name:		draft-ietf-emu-eap-tls13
    Revision:	00
    Title:		Using EAP-TLS with TLS 1.3
    Document date:	2018-05-29
    Group:		emu
    Pages:		18
    URL:            https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tls13-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
    Htmlized:       https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13

    Abstract:
       This document specifies the use of EAP-TLS with TLS 1.3 while
       remaining backwards compatible with existing implementations of EAP-
       TLS.  TLS 1.3 provides significantly improved security, privacy, and
       reduced latency when compared to earlier versions of TLS.  This
       document updates RFC 5216.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

---

From: Jouni Malinen <[email-masked]>
Date: Fri, 1 Jun 2018 00:48:29 +0300

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