On Thu, 14 Nov 2002, Richard Levitte via RT wrote: > Can it be shown that this is a problem at a TLS level? I'd hate to > make the proposed change just to discover that it breaks > interoperability with other TLS clients and servers.
RFC 2246 is very vague: """ 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. """ [looks like this was copied directly from Netscape's SSLv3 docs] What "conventional" is supposed to mean in this case is totally unclear to me. If I read this with no other knowledge, I would probably assume conventional == compatible with PKCS #3, since that was the DH standard of choice around the time SSLv3 came out, and since Netscape probably used B-SAFE for the initial SSL implementations. OTOH, who knows? Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone should contact the TLS WG and ask for a clarification on this issue? [I'll do it if nobody else is interested] -Jack ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
