Hi Alan, I see that the thread is continuing and that perhaps my reply will even become stale as I write it, but I'm replying to your note instead of the tip of the thread because it has good context for making some broader points that I would like to make.
On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote: > 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. My understanding of the discussions involving the TLS WG are that we forked off into two sub-threads: one about the use of TLS Exporters for key derivation (the one this is a reply to), that largely concluded with agreement on a simple change to make, and the other sub-thread about the protocol element known in -13 as the "commitment message". With respect to the exporter usage, I do see you had asked about using the type-code as the exporter context value that Martin didn't see much value in, but I am willing to accept that as a boon for safety of portability to other TLS-using EAP mechanisms. (I do note that the current editor's copy shows calls to TLS-Exporter() with only two arguments, but three are required; the construction there also seems to include a propspect for violation of the requirement that "one label is not a prefix of any other label" when both regular one-byte and extended type codes are used, but if the type code is meant to be the context argument I believe that risk goes away.) With respect to the "commitment message", I thought we had a discussion that revealed that the mechanism in the -13 could not fulfil its stated purpose, and that also called into question whether that stated purpose was actually the right thing that the protocol needed. My understanding, therefore, was that the TLS WG could not contribute further insight until there was a revised proposal from people who understand the needs of the EAP-TLS protocol from TLS that would both satisfy the needs of EAP and actually be achievable. > 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. I think this is becaues the TLS WG members (in aggregate) do not have a clear picture of what property or properties EAP-TLS will require from TLS that led to the need for an additional message when using TLS 1.3 as opposed to the RFC 5216 case with TLS 1.2. The prospect of an "authenticated signal from TLS to EAP-TLS that the authentication completed successfully" was mentioned, but I did not have the sense that there was universal agreement of that as the sole relevant property. > 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? Well, the text of the -13 contains a protocol mechanism that cannot deliver its stated purpose, so I will continue to hold a Discuss position if that remains. One Discuss ballot does not have to block the work indefinitely (the shepherding AD can request a different IESG balloting procedure be used), and I leave it between the WG and Roman whether to attempt that route. It is perhaps possible that (as John noted downthread) the text about the commitment message was badly written, and that just changing the surrounding description could work, but that gets back to the question I mentioned above of what properties EAP-TLS actually requires from TLS. -Ben > * 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwNRryTgg$ > > > > > > 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. > > > > _______________________________________________ > TLS mailing list > t...@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$ > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
