Alan DeKok wrote: >Does that mean all open issues have been addressed and resolved? > >The current suggestion from Eric is to *not* use application data, but to use >>CloseNotify instead. Does this mean the earlier discussion was wrong, or is >the >current suggestion wrong? Are we allowed to dig into reasons *why* we're >doing >this? > >I'm a little taken aback at the appeal to authority, and the opinion that the >>"best way forward" is to just publish a document we don't understand. > >I'll also note that you're defending the *process*. You're not defending the >>*content* of the draft. So do you stand behind it? i.e. do *you* have >reasons >why this behaviour is necessary? The above summary from 2.5 years >ago discusses >*what* was decided. The draft (and the summary) still makes no >mention of *why* >it's done, or why it's useful. > >The purpose of the draft is not to just publish "something". The purpose of >the >draft is to publish a clear, secure, spec for EAP-TLS 1.3. The current >discussion >does not give me confidence that we're making progress.
I seriously don't know where you got all of the above from. I only summarized the earlier discussion. I did not state any opinions. I think the group needs to discuss if -13 or -14 can be a basis for publishing or if we need substantial changes. The version the working group wants to publish also needs to pass IESG, that is a fact. The suggestion that EAP-TLS 1.3 should document detailed interaction with the informal EAP state machine is very new. This is something RFC 5216 leaves completely to the implementor, but as it is important to security I think it might be good idea to do. Regarding the EAP/EAP-TLS/TLS 1.3 interaction I don't think there are any really good short term solution. The chosen mechanism will likely have significant drawbacks and tradeoffs. My personal opinion is that the application data commitment message seems to be a bit less problematic then close_notify. None of them are an "alternative success", if that is what is needed, I don't think any of them work. The current objective status (without defending or offending anybody) is that if the WG cannot agree on adding clarifications and smaller updated to -14, EAP-TLS 1.3 will likely be significantly delayed. The comments on -14 in the WG so far is that it should not progress and that decisions need to wait until IETF 110 hackaton and EMU meeting. Delaying may be the right option, but the WG should be aware of this. A couple of weeks ago, I understood you position as moving forward with either version was the most important goal. Cheers, John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
