[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] NIST TLS recomendations
As many of you are aware, publication of NIST SP
800-56A establishes new requirements for federal
agencies, including KDFs recommended for use with
certain key establishment algorithms. Since
current protocols do not use the KDFs specified
in 800-56A, NIST has approved certain KDFs for
use in particular contexts until the 800-56A KDFs
become more widely accepted. The TLS KDF has been
approved for use by government agencies in the
context of the TLS protocol through the end of
2010. One of the security ADs requested that
NIST review that decision to determine under what
circumstances we can extend that approval indefinitely.
Upon our review of the TLS protocol (as specified
in draft-ietf-tls-rfc4346-bis-01), we noted that
the IETF has up to this point made the design
decision not to use the key derivation function
specified by NIST SP 800-56a. This KDF provides
certain guarantees as to the security of schemes
that use it. We therefore have evaluated whether
those same guarantees are provided within the
currently specified TLS v1.2 protocol. This
process led us to recommend the following
modifications to TLS v1.2 addressing both the
security issues that would be resolved by using
our KDF, and other security issues that arise in
the context of the TLS protocol:
Page 20-21: Section 6.2.3.2 under IV
The document specifies that the IV SHOULD be
generated by method (1) or (2) and MAY be
generated by an alternate method. There is,
however, no language forbidding the generation of
IVs by a fourth unlisted method. If a fourth
method is used, the protocol will not fail but
may be insecure. Therefore we recommend adding
language forbidding the use of an unlisted method for IV generation.
Page 22: Section 6.2.3.2 under implementation note:
This section suggests but does not mandate a
measure to protect against timing attacks. We
recommend that this measure be mandated.
Page 27: Section 7.2.2
While it is required that certain alerts must be
fatal, it is not currently required that said
alerts are sent in the first place. For example,
if the client certificate is not of the
negotiated type, but the server is capable of
parsing the certificate, we believe that a
compliant implementation of TLS should reject the
certificate and send a fatal error
(unexpected_message most likely,) however the
document does not currently seem to mandate this.
We recommend that the conditions under which any
fatal alerts are mandated be added.
We also recommend that the following alerts, not
currently listed as fatal, be made automatically
fatal: bad_certificate, unsupported_certificate,
and certificate_revoked. Ideally, we would
recommend that expired_certificate be made
automatically fatal as well, but we understand
that expired certificates are currently
sufficiently pervasive that this may not be a viable option.
The document allows compliant implementations of
TLS 1.2 to send the decryption_failed alert. The
inclusion of this alert has known security flaws
[CBCATT]. We recommend that compliant
implementations of TLS 1.2 MUST NOT generate this
alert but SHOULD be able to parse such an alert.
Page 45: Section 7.4.1.4.3
This section does not explicitly forbid a client
from sending certificate URLs when the server and
client have not explicitly agreed to support this
option. In order to address this ambiguity, we
suggest changing the current wording from:
“In order to negotiate to send certificate URLs
to a server, clients MAY include an extension of
type "client_certificate_url" in the (extended) client hello…
“Servers that receive an extended client hello
containing a "client_certificate_url" extension,
MAY indicate that they are willing to accept
certificate URLs by including an extension of
type "client_certificate_url" in the (extended) server hello…”
to:
“Clients MAY negotiate to send certificate URLs
to a server. In order to do this, clients MUST
include an extension of type
"client_certificate_url" in the (extended) client hello…
“Servers that receive an extended client hello
containing a "client_certificate_url" extension
MAY indicate that they are willing to accept
certificate URLs. In order to do this, servers
MUST include an extension of type
"client_certificate_url" in the (extended) server hello…”
This mandates that the client and server signal
their intentions. The current wording could be misinterpreted.
Page 47: Section 7.4.1.4.5 (Truncated HMAC)
This section has the same MAY/MUST wording issue as section 7.4.1.4.3
Page 57: Section 7.4.8
If the optional hash is not included with the
client certificate URL, the server has no way to
verify the name under which the private key in
the certificate was used, since the certificate
will not appear in the generation of the finished
message. We therefore recommend that the certificate hash be mandatory.
Furthermore, we do not want the client to be able
to claim, after the fact, that a certificate with
a different name was used. The collision
resistance of the hash function is therefore
crucial. The algorithm mandates the use of SHA1
for the certificate hash. While practical SHA1
collision attacks have not yet been applied, we
should be prepared to face such attacks. We
therefore recommend that algorithm agility and
support for a stronger hash function, such as SHA
256 or SHA 384 (for suite B compatibility) be
added to this stage of the protocol.
Page 62: Section 7.4.9.1 under Note:
This section suggests a procedure to prevent the
Bleichenbacher attack on PKCS#1 v1.5 encrypted
messages (specifically the pre-master secret.)
This procedure is not listed as mandatory. We
recommend that either this procedure be made
mandatory, or that all RSA encrypted messages be
required to use the OAEP padding scheme specified
in PKCS#1 v2. In the latter scenario, the
overwhelming majority of PKCS#1 v1.5 formatted
messages would need to be rejected by any compliant implementation.
There is ANOTHER note later in this section (at
the very end, after the implementation notes)
that discusses a variant of the Bleichenbacher
attack (by Klima, Pokorny, and Rosa – see
[KPR03]) that depends on the server reporting on
errors found in the version number included in
the RSA-decrypted premaster-secret message.
Therefore, the draft’s weak statement to the
effect that servers shouldn’t generate an alert
if there is such a problem should also be
strengthened to a MUST NOT. In fact, it should be
a general rule that decryption problems with PKCS
#1.5-formatted messages MUST NOT trigger actions
that are observably different than the actions
that would be taken if there were no problems.
Page 62-63 Section 7.4.9.1 under the second implementation note:
This section states that RSA operations SHOULD be
done in such a way as to prevent timing attacks.
We recommend changing this to MUST. We further
recommend that precautions against timing attacks
be made for other key exchange techniques, such
as those based on permanent Diffie-Hellman parameters.
Page 67 Section 8.1.2
We recommend that the leading zeroes of a
Diffie-Hellman-generated Z be RETAINED when it is
used as a pre_master_secret, so that the input to
the master_secret computation will have predetermined length.
Page 81 Section A5.
This section deprecates anonymous DH, which
hopefully means that no compliant version of TLS
1.2 will support this mode, (or any other
completely anonymous mode.) The rest of the
document, however, is written with the
implication that anonymous modes exist and are
allowed, albeit strongly discouraged, and server
authentication is only explicitly required in
section F.1.1.1 under warning (which is in the
implementation recommendations section, so it is
not clear that this is actually a requirement),
and then only under certain poorly defined
circumstances. It is important to note that as
long as the client supports anonymous key
exchange, the server’s policies regarding
anonymous key exchange (and any other crypto
parameters) become irrelevant, because any party
claiming to be the server can arbitrarily select
from the parameters offered by the client. We
recommend that all references to anonymous key
exchange that do not explicitly indicate that
anonymous key exchange MUST NOT be supported be
removed from the document or modified in such a
way that they do explicitly forbid anonymous key exchange.
The following comments are not security related,
but we did notice a few editorial mistakes and nitpicks.
Page 5: Section 1.1 is listed twice.
Page 24: Section 6.2.2 Implementation note
The first sentence reads “the currently defined
which requires the most material is
AES_256_CBC_SHA…” This is ungrammatical. It
should most likely read, “the currently defined
CIPHERSUITE which requires the most material…”
Page 33: Section 7.3
The statement
“If the client has sent a certificate with
signing ability, a digitally-signed certificate
verify message is sent to explicitly verify the certificate,”
is incorrect and misleading. If anything, this
message verifies the client’s possession of a
particular private key, and demonstrates (to the
server) the client’s knowledge of the form of the
handshake messages that have been exchanged up to
this point in the protocol. A certificate is
“verified” by checking the CA’s signature on the certificate, etc.
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls