anonymous DH & MITM

Bodo Moeller moeller at cdc.informatik.tu-darmstadt.de
Fri Oct 17 08:09:30 EDT 2003


Tim Dierks <tim at dierks.org>:
> Ian Grigg <iang at systemics.com>:
>> Steven M. Bellovin:

>>> What's your threat model?  Self-signed certs are no better than ADH
>>> against MITM attacks.

>> I agree.  As a side note, I think it is probably
>> a good idea for TLS to deprecate ADH, simply
>> because self-signed certs are more or less
>> equivalent, and by unifying the protocol around
>> certificates, it reduces some amount of complexity
>> without major loss of functionality.
>>
>> (AFAIK, self-signed certs in every way dominate
>> ADH in functional terms.)

> In TLS, AnonDH offers forward secrecy, but there are no RSA certificate 
> modes which do (except for ExportRSA). You can use ephemeral DH key 
> agreement keys with static certified DSA keys, though.
> 
> To be clear, this is a protocol issue, not really a self-signed certs vs. 
> DH issue.

>From a different point of view, this is not even a protocol issue ...
it is an RSA issue:

When using self-signed certificates, nothing stops you from creating a
new key and certificate every now and then.  The only slight problem
is that key generation for RSA is quite slow, compared with key
generation for logarithm-based cryptosystems; you probably wouldn't
want to create an RSA key for every incoming connection.  But, on
typical server hardware, it is no problem at all to create an RSA key
every couple of minutes or so.

While generally among the RSA-based TLS ciphersuites, only the
RSA_EXPORT ones provide forward secrecy (thanks to an ephemeral
512-bit RSA key), in the case of self-signed certificates the
distinction between export-restricted and other RSA ciphercuites is
not an issue as far as forward secrecy is concerned.

[Even when using "proper" certificates from some CA, you could provide
forward secrecy for RSA ciphersuites: Instead of obtaining an
end-entity certificate and directly using it on the TLS cipher, obtain
a CA certificate with nameConstraints appropriately limited.  Then the
server can sign its own end-entity certificates without resorting to
"self-signed certificates" in the usual sense.  This allows the server
to use newly created keys whenever it feels like it.]

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list