[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