[TLS] Re: NIST TLS recomendations

[Simon Josefsson <jas@xxxxxxxxxxx>]

Bodo Moeller <bmoeller@xxxxxxx> writes:

>> I believe fully anonymous ciphers are a useful feature of TLS, and
>> that they should stay.  Client/server authentication can and do happen
>> via other protocols than TLS, and those protocols can use TLS channel
>> bindings to protect against man in the middle attacks, if necessary.
>
> 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.
>
>    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: These ciphersuites MUST NOT be
>    used by TLS 1.1 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 };

Nice!  I like the text.

I think we should avoid using the word "deprecated" though.  I believe
there are good enough use cases to provide full support for DH_anon;
opportunistic encryption is one of them.  (And yes, I know that
SMTP/etc typically use DHE and not DH_anon, and that is fine by me.
There are other protocols than SMTP, some may need DH_anon.)

I believe we should interpret "deprecated" in RFC 4346 as a "MUST NOT
... unless specifically requested", and clarify that in RFC 4346bis.

The DH_anon ciphersuites have one known weakness, that is how they
were designed.  That is similar to NULL encryption.  Both ciphersuites
allows applications to use TLS to gain many of its advantages, but one
feature (authentication and encryption, respectively) is disabled due
to policy reasons.  Neither DH_anon or NULL should be used generally,
unless specifically requested by the application.

How about this text:

    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.  These ciphersuites MUST NOT be used by
    TLS 1.1 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, or when the architecture demands a fully anonymous
    channel.)

     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 };

Thanks,
Simon

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