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

From: [email-masked] (Peter Gutmann)
Date: Thu, 01 May 2008 22:45:14 +1200

Yoav Nir <[email-masked]> 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.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 May 2008 14:35:50 +0300

> TLS-EAP if identity protection is really such a big deal).

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

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 10 May 2008 00:18:59 +1200

Yoav Nir <[email-masked]> writes:

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

Why?  It's just another extension, the server can throw it away if it doesn't
know what to do with it.

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

Right, but that's very specific to browsers, and assumes an interactive
terminal with a user sitting there able to process messages.  What's the
target audience for this mechanism?  How many years will it be before browsers
even implement this, if they ever implement it at all?  Given EAP's existing
use with secure tunnels in which your VPN software transparently opens a
tunnel to the remote system, and that's it, there's no need for any user-
interaction facility.  I'm not saying it should be scrapped, but that we
should consider how it's likely to be used and optimise it for the most likely
usage scenario(s).

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

When it comes to usability they're usually wrong (and I mean specifically
security geeks vs.interaction designers).  Geeks like building in fancy stuff
that only other geeks would ever care about but that (at best) provides little
benefit for users and (at worst) makes their life much, much harder, and
[insert long rant here, or see Cranor and Garfinkel's book] :-).

Why not just make it an option in the protocol and let implementors decide?
That way the market gets to decide what they consider most important.  An
extra tag in a client hello is a pretty small price to pay...

Peter.