Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

From: John Mattsson <[email-masked]>
Date: Wed, 3 Feb 2021 13:32:24 +0000

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Feb 2021 08:43:44 -0500

> 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'm asking you as author to understand, explain, and defend the draft that you wrote.  The issue is *exactly* that you didn't state 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.

  Jouni Malinen brought up the question of RFC 4137 2.5 years ago, in the message you referred to recently.  This isn't new.

> 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.

  Such as?

> 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.

  Why?

  Perhaps the draft could be updated to *explain* these issues?  I'm still rather surprised that with open issues, the suggestion was that the "best way forward" was just to publish the draft.  It's simply not.

> 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 de…

  No.  I am never of the opinion that the most important goal is to publish.

  While timeliness is important, if we don't *understand* what we're publishing, then that is a total show-stopper.  We have to hold off publishing "something" until we understand exactly what we're doing.

  While I mostly like -13, it's not clear to me what, if any, utility the commitment message has.  When I ask "what does it do, and why", it's not helpful to answer "we added it years ago".

  If the draft cannot explain the pros and cons of it's choices, then the draft should be updated to do that.  If it's not clear *why* content is in the draft, then we should figure it out.  That's why I'm asking questions, and why I would very much appreciate answers to those questions.

  Alan DeKok.