Subject: [secdir] secdir review of draft-rescorla-tls-suiteb-10

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 6 Nov 2008 10:16:16 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments. I apologize
for the tardiness of these comments.

This document provides a brief overview of Suite B cryptography
and two profiles with specific requirements that TLS servers and
clients can meet in order to satisfy the Suite B requirements
while retaining some backward compatibility with older code,
if desired.

Before reading this document, I was not really familiar with the
Suite B requirements. The document provided a clear and concise
introduction to the topic with references to more information.

The requirements listed in the document seem to meet the implied goal
of ensuring secure interoperation between Suite B implementations
while allowing for less secure interoperation with older code.

I do not have any major concerns with this document. I wonder
about the following text in section 4 (in the requirements on
clients implementing the Suite B transitional profile):

   o  A Suite B transitional TLS version 1.1 or earlier client MUST
      offer one cipher suite for each supported security level.

This sounds like the client MUST offer only one cipher suite
for each supported security level, presumably the cipher suites
mentioned in the next two sentences. Actually, I think it is
permitted for such a client to offer other cipher suites in
order to achieve interoperability with non-Suite B compliant
servers, as mentioned in the next bullet. Therefore, I suggest
that the text quoted above be changed to something like this:

   o  A Suite B transitional TLS version 1.1 or earlier client MUST
      offer at least the cipher suites described in the next two
      sentences for each supported security level.

A client that does offer many cipher suites in order to achieve
interoperability with non-Suite B compliant servers is subject
to a downgrade attack. A similar vulnerability exists for servers
that wish to interoperate with non-Suite B compliant clients.
Although this threat is obvious to skilled practioners, I think
that it should be mentioned in the Security Considerations
section of this document since it is a significant vulnerability
associated with the recommendations contained in this document.

I did notice two minor errors in the document. In the last bullet
of the introduction, "An transitional" should be "A transitional".
And just before the text quoted above, the word "and" is missing
from the preceding sentence. That sentence should read as follows:

   For a client to implement the Suite B transitional profile, it MUST
   implement TLS version 1.1 or earlier and the following cipher suite
   rules apply:

To summarize, I am not an expert in Suite B cryptography but
I think that this document is beneficial and should be approved.
However, the shortcomings that I have pointed out should be
corrected before publication.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Russ Housley <[email-masked]>
Date: Sun, 16 Nov 2008 17:05:19 -0500

Steve:

Thanks for the review.

>       sentences for each supported security level.

I suggest:

    A Suite B transitional TLS version 1.1 or earlier client MUST offer
    the cipher suite for the 128 bit security level, the cipher suite for
    the 192 bit security level, or both.   For the 128 bit security level,
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be offered in the
    ClientHello message.  For the 192 bit security level,
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the
    ClientHello message.  One of these cipher suites MUST be the first
    (most preferred) cipher suite in the ClientHello message.

>associated with the recommendations contained in this document.

Due to the hash that is computed over the entire handshake, a 
man-in-the-middle cannot remove cipher suites from the offer without 
being detected.  However, if a TLS client offers many cipher suites 
in order to achieve
interoperability with non-Suite B compliant servers, then the client 
is subject to a TLS server selecting the least secure that is 
offered.  The TLS server gets to do the picking from the list offered 
by the TLS client, so I am do not see the "similar vulnerability."

>    implement TLS version 1.1 or earlier and the following cipher suite

I fixed these editorial problems.

>corrected before publication.

Thanks.

Russ