Re: [TLS] draft-nir-tls-eap-03

[Yoav Nir <ynir at checkpoint.com>]

On May 1, 2008, at 1:45 PM, Peter Gutmann wrote:

Yoav Nir <ynir at checkpoint.com> writes:

Regarding section 4.2 (comment (5)) I also believe that identity protection

is important, but that belief is not universally shared. For example, the

TLS-PSK protocol does not provide it. I'm not sure what I can do to elaborate

more on this, except to say (as we have) that "we believe that identity

protection is a worthy enough goal, so as to justify the extra round-trip.".

Can you suggest anything stronger?

What about allowing the client to specify whether it wants identity protection
or not, to save the extra RTT?  All you'd need is to allow the client to
specify their identity in the hello (as the draft indicates), if the server
gets a client ID as an extension in the hello then they can go straight to the
fastpath version, otherwise there's an extra RTT.  Identity protection seems
to be one of those things that only geeks actually care about - I've never
encountered any user that's even asked about this, but I have had several
queries from users working in resource-constrained environments about how to
minimise the handshake overhead, so a fastpath option would be a good thing.

(Alternatively, make fastpath the default and do an anon-DH + rehandshake with
TLS-EAP if identity protection is really such a big deal).

Peter.

I personally don't like that for several reasons:

1. While I trust TLS implementations to be able to ignore extension indications that they don't know (because there are a lot of extensions), I think sending an identity buffer in a new handshake message to an unsuspecting server may cause problems.

2. In a browser scenario, you may get redirected to an https page at any time. So either your browser stores a fixed identity for all TLS sessions that may come, or else you get a pop-up asking for your userid whenever you surf to an https site. It only makes sense to query your identity *after* the client got an indication from the server that it supports TLS-EAP, or even better, after the client verified the gateway's certificate.  So instead of prompting you "Enter userid to send to https://www.hotmail.com" you can get something nice like "Enter userid to send to www.google.com signed by VeriSign Class 3 Public Primary CA", which the PKIX guys would love.

3. There's lots of stuff only geeks care about, but they're usually right.

Yoav

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls