Hi, I can live with any version, the important thing is that interoperable implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
We (the authors) have addressed all the comments from IESG/TLS WG in GitHub. https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master Text format: https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt The diff can be found here: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt This would be ready for submission but I think the Implementors, WGs, Chairs, Shepard, ADs need to agree on the direction before we do that. The two important technical changes from -13 are (1) Changing key derivation (2) Changing Commitment message to close_notify The key derivation changes are good and more modern. I personally like the change but the change but I don't think it is essential and was not done for security reasons. The close_notity changes are not only positive as it sometimes introduce an additional roundtrip. The Commitment message can according to specification be sent with the server Finish even if some/most/all implementation does not seem to allow this. If the commitment message cannot be send with Finished in practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 and EAP interacts. I am not sure I fully agree with the layer violation argument, my interpretation was that this was information for the EAP state machine which is the application using TLS. Maybe the text regarding the commitment message was badly written and should have talked about the EAP state machine more instead of TLS.... We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward: A. Add (1) and (2) B. Only add (1) C. Only add (2) D. Do not add (1) or (2) I assume implementors (Alan, Jorge) are fine with all other changes since -13. Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as we agree on a way forward we can update and submit a new version within 24 h. Cheers, John -----Original Message----- From: TLS <tls-boun...@ietf.org> on behalf of Jorge Vergara <jovergar=40microsoft....@dmarc.ietf.org> Date: Friday, 29 January 2021 at 00:57 To: Alan DeKok <al...@deployingradius.com>, Martin Thomson <m...@lowentropy.net> Cc: "TLS@ietf.org" <tls@ietf.org>, EMU WG <e...@ietf.org> Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) I am in favor of sticking to draft-13. There was some discussion about whether draft-13 contained a TLS layering violation, but I believe that discussion concluded that it does not. As noted, discussion has mostly stalled since then with a few additional ideas surfacing that have added round trips. Other threads are now popping up expressing dissatisfaction with the extra round trip. Alan mentions that betas may be months out for his product line - for Microsoft and Windows, the situation is much tighter. If we cannot reach consensus quickly we will need to push this out of our 2021 release cycle. Seeing as we're sitting on draft-13 with multiple implementations available, I would really prefer to reach consensus to finalize draft-13 and get this into the hands of customers this calendar year. Jorge Vergara -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: Saturday, January 23, 2021 2:28 PM To: Martin Thomson <m...@lowentropy.net> Cc: <tls@ietf.org> <tls@ietf.org>; EMU WG <e...@ietf.org> Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) We're approaching 2 weeks since the last discussion of this topic. This document has been in development for 3 years. We desperately need to finish it. IMHO waiting another 6 months is not an option. Even 3 would be worrying. We have multiple inter-operable implementations which have implemented draft-13. That work over the last few months have resulted in implementors making plans to do beta testing in the next few weeks. Those plans have been put on indefinite hold, due to the recent request for changes. I understand getting feedback from the TLS WG is useful. But I would prefer to have consensus on a *solution*. Right now, we just have a series of proposed changes, with little to no discussion. We're getting to the point where we have to ship code as promised to customers soon (weeks, not months). We therefore need consensus, as soon as possible. My preference is to implement draft-13. We know the code works. People are ready to ship it. Any changes will add not just more months of standard discussion, but more months of interoperability testing. If there is no progress in EMU, we're looking at September for first betas. With no guarantee that there won't be further changes made after that. So the question is: * are the draft-13 0x00 byte and exporter *terrible* enough to delay the standard another 6 months? * if the answer is "no", then we can ship now. * if the answer is 'yes", then the next question is "when can we get this finalized?" "March" would be late. "July" is a major problem. > On Jan 12, 2021, at 10:22 AM, Alan DeKok <al...@deployingradius.com> wrote: > > On Jan 11, 2021, at 7:08 PM, Martin Thomson <m...@lowentropy.net> wrote: >> I was not exactly. I was thinking that EAP-TLS uses the unadorned string >> and other usages (that need a different MSK) define their own string as >> needed. > > Which is largely what was done for <= TLS 1.2. > > That choice made implementations more difficult. Not impossible, but > annoying. The other TLS-based EAP types are generally implemented as > variants of EAP-TLS. They re-use much of the EAP-TLS code. So every > difference is more code, and more things to test. > >> Though what you describe would scale more, if the ordinality of that scale >> is bounded by RFC numbers, defining the extra strings would not be that >> hard. You could provide some sort of infrastructure in the form of a >> recommended label prefix if you are concerned about misuse. > > I'm not sure EAP-TLS is the place to make recommendations for other EAP > types. There is a draft to deal with other EAP types: > > https://protect2.fireeye.com/v1/url?k=fe7995f2-a1e2acf7-fe79d569-86d2114eab2f-8b83bd94fff2883d&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-dekok-emu-tls-eap-types-00%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753309597%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DeTBptf92iMhYupJv9kRLl%252FzAV75fZXSbDjTI9sKu%252Bvs%253D%26amp%3Breserved%3D0 > > It's pretty trivial. Adding more complexity is annoying, but not much worse > than that. > > My preference is to remain with the EAP type as the context. The code is > simple, and it's easy to understand. But if it causes issues with TLS > review, we can change it. > > Alan DeKok. > _______________________________________________ Emu mailing list e...@ietf.org https://protect2.fireeye.com/v1/url?k=80417b72-dfda4277-80413be9-86d2114eab2f-701eaa3e4f1d35c4&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Femu%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753319592%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DJQCtoTOMTzouZnJ0ILj%252B8%252BtIpJW8t04HbSlDDGYf8VQ%253D%26amp%3Breserved%3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
