Eric Rescorla writes:
badra@xxxxxxxx writes:In EAP-TLS, an implementation of TLS for Wireless LAN and later for WiMAX,the client is authenticated based on the certificate's use. This is the initial motivation of this work.Yes, but I don't think this really explains why the certificate needs to be kept secret or why the double handshake technique isn't good enough.
Hi Eric,IMHO, double handshake technique isn't good enough to many environments, especially in performance-constrained environments. In addition:
- As you cited in your early mail, double handshake needs two sets of crypto computations and 4 RTTs. The number of RTT significantly increases when using TLS over EAP or UDP. Moreover, the client and the server need to encrypt/decrypt the whole messages of the second handshake.
- Double handshake reduces the server performance by a factor of 2 or 3 at least.
- In the case where the client has no certificate and the server isn't configured to accept connexions from unauthenticated clients, we can't stop the TLS negotiation early. So the server is overloaded for nothing: the first handshake is already done and the sever doesn't receive a certificate from the client. In the ciphersuites approach, the server and the client can detect such configuration early during the hello phase.
- With double handshake, the "privacy" and "no privacy" cannot be implemented together. I mean TLS servers aren't so smart to do that without external configuration and that the client cannot set or negotiate "privacy" with a given server.
- Configuration cost. Best regards, Badra _______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls