Re: [TLS] Re: NIST TLS recomendations

[Bodo Moeller <bmoeller@xxxxxxx>]

On Thu, Nov 02, 2006 at 09:15:19PM +1300, Peter Gutmann wrote:
> Bodo Moeller <bmoeller@xxxxxxx> writes:

>> This is exactly right, however it certainly is reasonable to add some
>> language to the specification that points out that these ciphersuites should
>> *usually* not be enabled.  Here is a proposal for A.5.

> Isn't this just posturing though?  Since people are currently doing DH_anon
> via DHE, it's not going to make much difference whether DH_anon is enabled or
> not.  Or should the text include a note to say that current practice is to do
> DH_anon via DHE, so enabling DH_anon isn't worth the bother and you may as
> well leave it disabled?
> 
> (I'm not terribly fussed about this, people are going to program FORTRAN no
> matter what language you give them, but it'd be nice if the spec at least
> acknowledged current practice in order to guide both implementors and users).

Certainly doing "DH_anon" via DHE is currently the most frequent case
of an unauthenticated handshake found in practice, and it is has some
advantages over actual anonymous DH since clients can cache server
certificates in sort-of SSH style.  (If the client software doesn't do
this automatically, you should still be able configure your preferred
SMTP server's self-signed certificate into your TLS-aware SMTP client,
for example.)

There is some use of the actual DH_anon ciphersuites in protocols that
use other means for authentication, though.  Of course, those who
implement these specific protocols know very well which ciphersuites
they need, so they don't depend on the TLS specification explaining
these issues -- it would just be weird if the TLS specification
stricty forbade using these ciphersuites.

Here's a new text proposal for A.5.  (One additional correction here
is that I replaced "TLS 1.1", which was left in place from RFC 4346,
by "TLS 1.2", which is what draft-ietf-tls-rfc4346-bis-##.txt is
actually about.)

   The following cipher suites are used for completely anonymous Diffie-
   Hellman communications in which neither party is authenticated. Note
   that this mode is vulnerable to man-in-the-middle attacks.  Using
   this mode therefore is deprecated for most purposes: These
   ciphersuites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange.  (Anonymous key exchange may sometimes be acceptable, for
   example, to support opportunistic encryption when no set-up for
   authentication is in place, or when TLS is used as part of more
   complex security protocols that have other means to ensure
   authentication.)

    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };

   Note that using non-anonymous key exchange but not verifying the
   certificate is essentially equivalent to anonymous key exchange,
   and the same precautions apply.  While non-anonymous key exchange
   will generally involve a higher computational and communicational
   cost than anonymous key exchange, it may be in the interest of
   interoperability not to disable non-anonymous key exchange when the
   application layer is allowing anonymous key exchange.

Bodo


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls