Here are my answers as a client implementor. You'll see our implementation has had more time to bake with the application data, but I don't think either is technically problematic. I do favor the application data because I believe it is better suited for the semantic purpose as a protected result indicator for EAP-TLS. When close_notify was floated in the group and put in draft-14, the group was very specifically discussing the semantic of "no more messages will be sent" - for which close_notify carries that intent very clearly. The group has now realized that a protected result indicator is needed instead, and this is very different from "no more messages will be sent." It's my opinion that close_notify is less suited for this new purpose.
>1. Have you implemented the zero byte application record signa? If not, why >not?l Yes. >a. Is it sent after receiving the client finished? Observably in server implementations we are testing against, yes. >b. Do you anticipate problems if the application record comes before or after >a NewSessionTicket message? No. >c. did you run into any issues with this mechanism? No. >2. Have you implemented the close notify method? If not, why not? Yes, but testing isn't finished. >a. Is it sent after receiving the client finished? We're ironing out a few implementation issues. >b. Were you able to cause the message to be sent for the server or determine >that the message was received for the peer/supplicant? We're ironing out a few implementation issues. >c. Did you run into any issues with this mechanism? Yes, as above - but theoretically I don't see a technical issue once the kinks are ironed out. We believe the signal should be accessible to our client implementation. Jorge Vergara
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
