Re: [TLS] [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt
On Feb 2, 2021, at 11:31 AM, John Mattsson wrote: > 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. 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 WG meeting at IETF 110 > meeting, but -14 looks like the only thing that can reach agreement to be > published at this point. IMHO we are still nowhere near agreement. There are many open questions which have not been resolved. Alan DeKok. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-ietf-emu-eap-tls13-14.txt
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: "internet-dra...@ietf.org" Date: Tuesday, 2 February 2021 at 17:28 To: John Mattsson , John Mattsson , Mohit Sethi 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-friel-tls-eap-dpp-01
Hi all, I have watched the EMU presentation about draft-friel-tls-eap-dpp-01 at the last IETF meeting (see ) https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-dpp-00and, at that time, I was confused about the scope of the proposed work. Having read into the WiFi DPP specification in the meanwhile I believe that this is a very useful contribution, which simplifies the enrollment of WiFi devices to a network. Hence, I am in support of the document*. Ciao Hannes *: There are various open issues here and there in the draft that need to be worked out. The worksplit between EMU and the TLS WG is also something that requires the chairs to look into. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
