[114372] in cryptography@c2.net mail archive
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
daemon@ATHENA.MIT.EDU (Tim Dierks)
Thu Jan 31 15:19:28 2008
Date: Thu, 31 Jan 2008 14:51:38 -0500
From: "Tim Dierks" <tim@dierks.org>
To: "=?ISO-8859-1?Q?Philipp_G=FChring?=" <pg@futureware.at>
Cc: "Eric Rescorla" <ekr@networkresonance.com>,
Cryptography <cryptography@metzdowd.com>,
"Rasika Dayarathna" <dayarathna@gmail.com>
In-Reply-To: <200801310304.01613.pg@futureware.at>
On Jan 30, 2008 9:04 PM, Philipp G=FChring <pg@futureware.at> wrote:
> Hi,
>
> > Huh? What are you claiming the problem with sending client certificates
> > in plaintext is
>
> * It=B4s a privacy problem
> * It=B4s a security problem for people with a security policy that requir=
es
> the
> their identities to be kept secret, and only to be used to authenticate t=
o
> the particular server they need
> * It=B4s an availability problem for people that need high-security
> authentication mechanisms, combined with high-privacy demands
> * It=B4s a identity theft problem in case the certificate contains person=
al
> data
> that can be used for identity theft
I totally disagree that this is a material problem that is in any meaningfu=
l
way impeding the use of SSL client certificates (there are totally differen=
t
reasons that client certs aren't being widely adopted, but that's beside th=
e
point).
However, TLS supports what you want right now: just do the initial handshak=
e
without client auth, then renegotiate after the session encryption starts.
The renegotiation will happen under the encrypted, identity-protected and
server-authenticated session, and client authentication can be requested in
the renegotiation; the client cert will then be confidential.
The reason nobody actually bothers to do this is because there's no custome=
r
demand (see paragraph 1).
- Tim
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
