Re: [TLS] Suggestion for Transport Layer Security (tls)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Suggestion for Transport Layer Security (tls)



Hi, Tim. 

I think that remote endpoint IP addreses are exposed to the client web
application through the server logs and the web server api.  The client
web application usually doesn't form TLS packets directly, but through
an API of some sort offered by the web server itself.  Should the web
server operator want to hide IP addresses of remote endpoints from the
client web application, they could alter what is exposed in logs and
throught the API available to the client.  I think its possible to
implement your suggestion by changes to the API and maybe by changes to
the web server itself (to have options to control whether IP addresses
are exposed), but that API and software is not the subject of the
protocol working group.

Genuine anonymity is hard to ever truly achieve in the internet or
electronically, and there are really just administrative limitations on
who knows or has access to the identity of the endpoints. Security in
TLS is based on proving knowledge of a private key in a public/private
key pair, which is a kind of identification.  Secure, genuine anonymity
and electronic cash (as distinct from traceable electronic payments) are
closely related problems, I think.  Solve either, and you'll be rich...

		--Dean


On Thu, 28 May 2009, tim robertson wrote:

> Hi, I have a suggestion for Transport Layer Security (tls). You should
> have a feature that makes the Transport Layer Security anonymous, so no
> ip address will be seen or recorded. It could work by the ip address
> being transformed into a random encrypted public key, so the web server
> will only see the encrypted public key and not the ip address of the
> computer. Can you pass on my suggestion?Thanks

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.