RE: [TLS] Comments on TLS identity protection

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: aerowolf@gmail.com> To: martin.rex@sap.com> Subject: Re: [TLS] Comments on TLS identity protection> CC: tls@ietf.org> > 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 <martin.rex@sap.com> 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> > TLS@lists.ietf.org> > https://www1.ietf.org/mailman/listinfo/tls> >> > > -- > > -Kyle H> > _______________________________________________> TLS mailing list> TLS@lists.ietf.org> 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