RE: [TLS] Comments on TLS identity protection

Eric:

I hope Im doing ok on CRLFs. I add them manually in my paragraphs, when I 
remember. As far as I can determine , there is no way for a  hotmail.com users 
to meet the IETF usability rules (wordwrap before 65chars, affixing CRLF each line),
I'm happy to be shown how, tho, by  power user! I'm keeping msn, tho, as it
gives me excellent IETF S/MIME from my EVDO PDA, via a webmail.
> > Peter Williams <home_pw@msn.com> writes:> > Id say the nth handshake can select to send "no server cert" whenever its > > cooperating to complete an anonymous-ciphersuite-targeted handshake.> > So, assume there are only two ciphers suite values in the HSM : RSA, RSA-ANON. > > There is no such thing as RSA anon in SSLv3 or TLS. 
For a long time Ive regarded SSLv3 as http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#8-1
Its an old bookmark!

it doesnt even contain a set of ciphersuite declarations. It clearly
reinforces what I said tho: server cert presentation is ALWAYS optional
architecturally, and ServerKeyExchange is then used, instead. Netcape
documents were never particular formal! They were always in a rush.

What I learned today is something i NEVER EVER REALIZED :-) was that the
ServerKeyExchange.RSA could be ephemeral. While I always knew about the 
"temporary key" idea (which demands a server cert...), I never equated it 
with the equivalent "ephemeral DH". If they had meant ephemeral RSA, they
would have used the word ... like DH! I reasoned. I was always interested in
the no-cert case, in any case, per the first line in the text in 7.6.3.
For no cert RSA, obviously they intended the RSA block to be used. How
otehrwise could key transport ever work... if you don't signal the 
public key!!?

It seemed so obvious to (a) do a full cert-based handshake (with no privacy) 
and then do an immediate second (full) handshake, "accelerated", referring
back to the full "previously cert chain verified" public key, whose chain
was verified properly just moments before, and stored in my client session context. 
It seemed silly to do all that chain checking work again, on the client. This way, 
the second handshake would be under the session protection of the first SSL 
Connection, giving basic privacy to the negotiation of the ciphersuites, 
etc. for the SSL connection that would then takeover.

Why would anyone want an attacker to see the good stuff!? like the ciphersuite
selection!!? So... handshake#1 is just a foil to boot handshake#2. This
was a variation from 10 years ago of the current argument over client 
id protection, from Ibrahim and co.

If TLS RSA CipherSuite DENY this mode (as I think they do, on simple reading), 
I will simply locally-define a local-RSA ciphersuite for use on handshake#2, that 
removes anything in the std RSA that follows from requiring server auth "via 
certs". I can declare this a profile, and shut up about it, here in standards land.

_________________________________________________________________
Fixing up the home? Live Search can help.
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=wlmemailtaglinenov06