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
