Re: [Emu] John Scudder's No Objection on draft-ietf-emu-tls-eap-types-11: (with COMMENT)

[Alan DeKok <[e-mail]>]

On Feb 14, 2023, at 4:24 PM, John Scudder via Datatracker <[e-mail]> wrote:
> ### Section 3
> 
> ```
>   Earlier TLS versions did not always send application data along with
>   the Finished message.  It was then possible for implementations to
>   assume that a receipt of a Finished message also meant that there was
>   no application data available, and that another round trip was
>   required.
> ```
> 
> This doesn’t quite make sense to me as written. Do you mean that earlier TLS
> versions always did not send application data along with the Finished message?=
> Note the significant movement of the word "always". The way it’s written right
> now, "did not always" implies earlier TLS implementations "sometimes did" send
> application data along with the Finished message, and if that was the case, I
> don’t see how (non-buggy) implementations could make the assumption you note.

  I think it's "always" did not send...  I don't want to get into details of TLS, but the EAP applications using TLS definitely assumed that "Finished" meant "no application data".

  I think the simplest thing to do here is to just remove "always":

	Earlier TLS versions did not send application data along with the Finished message.

> ### Section 4
> 
> ```
>   As the packet flows for resumption are essentially identical across
>   all TLS-based EAP types, it is technically possible to authenticate
>   using EAP-TLS (Type 13), and then perform resumption using another
>   EAP type, just as EAP-TTLS (Type 21).
> ```
> 
> Is “just as” in the last line, supposed to be “such as“? If “just as“ is
> correct, I don’t understand what’s intended.

  Perhaps remove "just as":

	Instead, this definition allows us to simplify references to EAP Types, by using a logical "Type" instead of referring


> ### Section 6.1
> 
> ```
>   Similarly, when the inner authentication protocol indicates that
>   authentication has succeeded, then implementations SHOULD cause
>   authentication to succeed for the entire session.  There MAY be
>   additional protocol exchanges in order which could cause other
>   failures, so success is not required here.
> ```
> 
> That last sentence doesn’t make much sense to me. I am guessing what you mean
> is something like, “The reason success is not mandatory but only recommended in
> this case is that we cannot preclude that an inner protocol might have
> semantics such that authentication can succeed but the overall exchange still
> can fail.”

  It's left over bits from multiple edits.  Perhaps:

There MAY be
additional protocol exchanges which could still cause failure, so we
cannot mandate sending success on successful authentication.


> Feel free to use those words if they make sense, or not, but as the text stands
> I had difficulty so I suggest some kind of clarification. At a minimum, it
> appears to me that the words “in order” should be removed?

  Yes.

  Alan DeKok.