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

From: John Mattsson <[email-masked]>
Date: Tue, 2 Feb 2021 16:31:36 +0000

Hi,

Our understanding is that draft-ietf-emu-eap-tls13-13 currently has no possibility to progress to the RFC editor’s que. To secure a place in the RFC editors’ que we have submitted version -14 that addresses all the comments in the IESG Discuss. -14 uses close_notify instead of a application data commitment message and slightly changes the exporter calls. We hope this version will clear the remaining Discuss. The only way forward at the moment is to publish and implement -14.

Implementors have expressed a preference for draft-13, but an even stronger preference to finalize and publish the draft. I hope the discussions will continue during the coming weeks and at the EMU WG meeting at IETF 110 meeting, but -14 looks like the only thing that can reach agreement to be published at this point.

John & Mohit

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, 2 February 2021 at 17:28
To: John Mattsson <[email-masked]>, John Mattsson <[email-masked]>, Mohit Sethi <[email-masked]>
Subject: New Version Notification for draft-ietf-emu-eap-tls13-14.txt

A new version of I-D, draft-ietf-emu-eap-tls13-14.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF repository.

Name:		draft-ietf-emu-eap-tls13
Revision:	14
Title:		Using EAP-TLS with TLS 1.3
Document date:	2021-02-02
Group:		emu
Pages:		32
URL:            https://www.ietf.org/archive/id/draft-ietf-emu-eap-tls13-14.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13
Htmlized:       https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-14
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-14

Abstract:
   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (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.  EAP-TLS with TLS 1.3 further
   improves security and privacy by always providing forward secrecy,
   never disclosing the peer identity, and by mandating use of
   revocation checking.  This document also provides guidance on
   authorization and resumption for EAP-TLS in general (regardless of
   the underlying TLS version used).  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: Alan DeKok <[email-masked]>
Date: Tue, 2 Feb 2021 11:47:54 -0500

> Our understanding is that draft-ietf-emu-eap-tls13-13 currently has no possibility to progress to the RFC editor’s que. To secure a place in the RFC editors’ que we have submitted version -14 that…

  The way forward is to resolve open issues.  Publishing the current draft would be premature.

> Implementors have expressed a preference for draft-13, but an even stronger preference to finalize and publish the draft. I hope the discussions will continue during the coming weeks and at the EMU…

  IMHO we are still nowhere near agreement.  There are many open questions which have not been resolved.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 2 Feb 2021 14:27:37 -0500

One note on a new issue in -14:

https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-14#section-2.1.2

  The diagram suggests that it's possible for the EAP-TLS server to separate the "TLS Finished" messages from the "NewSessionTicket" message.  There is no guidance as to how this is done.  After spending some time going through RFC 8446 and OpenSSL docs / code, it's not clear that this separation can be enforced by the application.

  Alan DeKok.