[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] Re: NIST TLS recomendations
Bodo Moeller <bmoeller@xxxxxxx> writes:
> So here's an updated proposal. This avoids the word "deprecated" (as by
> Pasi's and Simon's earlier remarks), and avoids the word "certificate":
>
> 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 of limited use: 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 without actually verifying
> the key exchange 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.
This looks fine!
Thanks,
Simon
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls