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

From: Peter Williams <[email-masked]>
Date: Tue, 19 Dec 2006 16:34:12 -0800

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. 
on handshake 1, changecipherspec completes session state using RSA-derived
master keying, having used/sent a server cert. 
 
On the second handshake, the server can no constrain the negotiation of ciphersuites 
to only offer only RSA-ANON. If the client accepts, if is accepting the possibility of 
no server auth (via certs). 
 
Of course, the second handshake is conducted within the SA of the first... 
which may well authenticate the server's public key anyways, without
using certs for that function, enough to validate the signature on the 
server key agreement message. Thius is consitent with IETF's RFC 1421 
practices, using public keys (only) from previous certificate-based sessions.
Now, I'm delighted to be corrected on this, in theory or  actual practice in 
commodity internet products. TLS's 1.0 "minor" changes to  SSLv3 are still 
new to me. I never bothered to read the TLS 1.0 
document carefully enough before, thus failing to recognize the notions 
of anon-ciphersuites, export-controlled key agreement , and its new fatal 
exception modes.
 
now IETF has endorsed the notion of RSA ephemeral, we just dump
the export control policy and exploit it!
 
Im going to read TLS 1.1 much more carefully tomorrow. Ill try
to backtrack any new control policy developments through TLS1.0
and back to SSL3. Im half hoping IETF already dumped RSA_EXPORT
as arcane, or at least increased the key length after 6 years!

> Date: Tue, 19 Dec 2006 15:41:57 -0700> From: [email-masked]> To: [email-masked]> Subject: Re: [TLS] Comments on TLS identity protection> CC: [email-masked]> > On every renegotiation, does the server have to reauthenticate itself> (present its certificate again)? Or can the credential on the client> side be cached to avoid that duplication?> > -Kyle H> > On 12/19/06, Martin Rex <[email-masked]> wrote:> > Eric Rescorla wrote:> > >> > > Good point.> > >> > > However, as you say in most cases the request for client auth> > > is contingent upon seeing the request and so a rehandshake is> > > required here in any case. A one-pass protocol wouldn't work> > > here.> >> > Correct.> >> > I had the same thought but completely failed to point this out.> >> > In the not uncommon case with IIS renegotiating after having> > evaluated the HTTP(S)-request, the one-pass protocol can not> > be used.> >> > -Martin> >> > _______________________________________________> > TLS mailing list> > [email-masked]> > https://www1.ietf.org/mailman/listinfo/tls> >> > > -- > > -Kyle H> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Get the Live.com Holiday Page for recipes, gift-giving ideas, and more.
www.live.com/?addtemplate=holiday

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 16:46:21 -0800

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

> of anon-ciphersuites, export-controlled key agreement , and its new fatal 

Huh? Nearly all of this stuff was in SSLv3--I don't know what "new
fatal exception modes" are but fatal exceptions were totall in
SLv3.

> as arcane, or at least increased the key length after 6 years!

TLS 1.1 forbids negotiating the RSA_EXPORT cipher suites. See
A.5 of RFC 4346:

   When SSLv3 and TLS 1.0 were designed, the United States restricted
   the export of cryptographic software containing certain strong
   encryption algorithms.  A series of cipher suites were designed to
   operate at reduced key lengths in order to comply with those
   regulations.  Due to advances in computer performance, these
   algorithms are now unacceptably weak, and export restrictions have
   since been loosened.  TLS 1.1 implementations MUST NOT negotiate
   these cipher suites in TLS 1.1 mode.  However, for backward
   compatibility they may be offered in the ClientHello for use with TLS

   <page break>

   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
   server did not choose one of these cipher suites during the
   handshake.  These ciphersuites are listed below for informational
   purposes and to reserve the numbers.

-Ekr