John Scudder has entered the following ballot position for
draft-ietf-emu-tls-eap-types-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document. I have a few questions and comments I hope may be of
use.

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

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

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

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?



_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to