Subject: RE: [TLS] Comments on TLS identity protection

From: Peter Williams <[email-masked]>
Date: Tue, 19 Dec 2006 22:54:21 -0800

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 <[email-masked]> 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

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Dec 2006 06:53:50 -0800

> gives me excellent IETF S/MIME from my EVDO PDA, via a webmail.

Prehistoric technology, dude! OK, I'll try to adjust.

> For a long time Ive regarded SSLv3 as http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#8-1

Here's the SSLv3 spec that I usually use as a reference.

http://wp.netscape.com/eng/ssl3/draft302.txt

You'll note that it's very similar to TLS :)

> documents were never particular formal! They were always in a rush.

I don't agree with this interpretation.

Here's the key text, from A.6.

   The following CipherSuite definitions require that the server
   provide an RSA certificate that can be used for key exchange.  The
   server may request either an RSA or a DSS signature-capable
   certificate in the certificate request message.

     CipherSuite SSL_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
     CipherSuite SSL_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
     CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
     CipherSuite SSL_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
     CipherSuite SSL_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
     CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
     CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
     CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
     CipherSuite SSL_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
     CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };

-Ekr