RE: [TLS] Comments on TLS identity protection

badra wrote:

> Other reasons are included in my last mail for why double 
> handshake isn't good enough, optimization is one of them.

I don't think any of the "reasons" lead to the conclusion that 
"double handshake isn't good enough"; let me explain why:

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

And why would anyone care about this? (Note that your proposal doesn't
help against intentional denial-of-service attacks either, only
accidental misconfiguration.)

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

See draft-simon-emu-rfc2716bis Section 2.7 for how a "smart" TLS
server can support both clients that support privacy and those that
don't. 

> - Configuration cost.

What configuration? A TLS server that supports both privacy and no
privacy doesn't need any configuration options to do so (it does
need the code to do double handshake, but new code would be required
for your proposal as well). A TLS client might concievably have 
configuration option "require privacy", but this applies to your 
proposal as well.

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls