When do I need to install dh parameters?

[Sam Varshavchik]

Nikos Mavrogiannopoulos writes:

> On 10/03/2010 12:14 AM, Sam Varshavchik wrote:
> 
>> I find that sometimes I can get through a handshake without loading DH
>> parameters, other times handshake fails unless I install them. As far as
>> I can see that's the only major difference between my code that works
>> without DH parameters, and the one that fails to handshake unless DH
>> parameters are installed. Am I on the right track, or are there also
>> other situations?
> 
> Depends on the ciphersuite chosen (by you or the peer). The DHE
> ciphersuites require them.

Thanks, but my question was, fundamentally, why would AES-256-CBC/RSA/SHA1 
be unavailable, and common ciphersuites for a session would include only DHE 
ciphersuites, like, AES-256-CBC/DHE-RSA/SHA1, so DH parameters are required.

The docs I read were easily understood in terms of requirements for 
temporary RSA parametes -- to support weak ciphersuites. But for DH 
parameters, the documented requirement was described as just to support DHE 
ciphersuites, but without explaining when DHE ciphersuites are required.

In one of my test suites, AES-256-CBC/RSA/SHA1 was easily negotiated. In 
another one, only a DHE ciphersuite could be negotiated, and it would fail 
unless I install DH parameters, and then the handshake easily produced a 
AES-256-CBC/DHE-RSA/SHA1 session. I was trying to understand why 
AES-256-CBC/RSA/SHA1 was dropped in that case, and not available in that 
specific test scenario.

By trial and error, I think I found at least a part of the answer: it seems 
to me that if the server's certificate includes the 
GNUTLS_KEY_KEY_ENCIPHERMENT flag, set by gnutls_x509_crt_set_key(), then the 
non-DHE cipher suites are available. Without this flag, only DHE 
ciphersuites are available for negotiation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20101003/58c6d7bc/attachment.pgp>