Subject: [TLS] NIST TLS recomendations

From: Ray Perlner <[email-masked]>
Date: Wed, 01 Nov 2006 09:19:52 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Nov 2006 15:54:31 +0100

Ray Perlner <[email-masked]> writes:

> 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.)

I don't read A5 that way.

Section A5 suggests (but no MUST NOT) that DH_anon for RC4/DES/3DES is
deprecated, which I'd agree to.

However, section A5 appear to permit DH_anon with AES128/AES256.

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.

/Simon

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Nov 2006 04:02:57 +1300

Simon Josefsson <[email-masked]> 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.

DH_anon is very widely used for opportunistic encryption in systems supporting
STARTTLS/STLS/AUTH TLS and similar mechanisms.

(Actually that's not 100% accurate, what's used is something like DHE with a
 self-signed cert that typically isn't checked, so it's a mechanism that acts
 like DH_anon without actually being DH_anon.  So I don't know if deprecating
 DH_anon will have much effect when the situations where it would be needed
 are using other mechanisms in the manner of DH_anon.  This is an interesting
 question, are you trying to deprecate the thing labelled DH_anon, or to
 deprecate the practice of making unauthenticated connections?).

Peter.

---

From: "Kemp David P." <[email-masked]>
Date: Wed, 1 Nov 2006 11:17:41 -0500

"Opportunistic encryption" sounds like a much more accurate
characterization
of anonymous/ephemeral sessions than does "protect against MITM
attacks",
the latter being precisely what unauthenticated encryption does NOT
provide.

-------

I believe the purpose of Mr. Perlner's request was to gain a sense of
the working group's opinion on the role of IETF security standards -- 
should the TLS spec focus on interoperability and permit a wide
spectrum in the protocol assurance of compliant implementations, with
NIST
Special Publications or FIPS profiling the higher end of the spectrum
for Government applications, or should the higher assurance
wire options become mandatory for TLS compliance?

My sense is that the AD's expectation is unrealistic and that NIST
will need to profile a subset of TLS for FIPS compliance after 2010,
but I'd be happy to be proven wrong.

Dave

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 10:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Re: NIST TLS recomendations

>protect against man in the middle attacks, if necessary.

DH_anon is very widely used for opportunistic encryption in systems
supporting
STARTTLS/STLS/AUTH TLS and similar mechanisms.

(Actually that's not 100% accurate, what's used is something like DHE
with a
 self-signed cert that typically isn't checked, so it's a mechanism that
acts
 like DH_anon without actually being DH_anon.  So I don't know if
deprecating
 DH_anon will have much effect when the situations where it would be
needed
 are using other mechanisms in the manner of DH_anon.  This is an
interesting
 question, are you trying to deprecate the thing labelled DH_anon, or to
 deprecate the practice of making unauthenticated connections?).

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 08:20:27 +0100

On Wed, Nov 01, 2006 at 09:19:52AM -0500, Ray Perlner wrote:

[...]
> the context of the TLS protocol:

Thank you for contributing the list of proposed modifications.
Just some brief comments at this time:

[...]
> document does not currently seem to mandate this. 

I don't think that this particular change is warranted.  In many
situations, servers request client authentication via a certificate,
but can tolerate unauthenticated clients as well.  In a scenario where
unauthenticated clients are welcome, authenticated clients may be
given the privilege to access services that are not available to
unauthenticated clients.  (E.g., for the case of an SMTP server, any
client can send e-mail to addresses that are local to the server; only
certain authenticated clients can send e-mail to remote addresses.)
There is no compelling reason to have the TLS handshake fail if a
client that tries to authenticate itself by presenting a certificate
presents a certificate that the server cannot handle: In this case the
client may simply end up as an unauthenticated client, which may very
sell sufficient for whatever services the client actually needs to
use.

If you think that the current wording is not strict enough, then the
change that should be done is not to force these alerts to become
fatal.  Possibly the specification should more clearly point out that,
in the situations where such alerts have to be sent by the server
since the are problems about verifying the client certificate, the
contents of the client certificate cannot be trusted in any way and
must be ignored.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 08:37:21 +0100

On Thu, Nov 02, 2006 at 08:20:27AM +0100, Bodo Moeller wrote:

[...]
> sell sufficient for whatever services the client actually needs to

Oops -- this should read: "..., which may very well be sufficient for
whatever services the client actually needs to use."

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 08:34:22 +0100

> However, section A5 appear to permit DH_anon with AES128/AES256.

This is true, but if you look at the rationale given in A.5 for
deprecating these three DH_anon cipersuites, it is quite clear that
the two AES DH_anon ciphersuites should have been deprecated too:

   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 and is
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   therefore deprecated.
   ^^^^^^^^^^^^^^^^^^^^

Probably this inconsistency was introduced when the specification of
the AES ciphersuites was merged into the main TLS specification.

Having said that, I agree that DH_anon ciphersuites should not be
deprecated!  In particular, anonymous key exchange course should not
be explicitly forbidden (as per the NIST recommendation).

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

Bodo

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Nov 2006 20:52:25 +1300

Bodo Moeller <[email-masked]> writes:

>In many situations, servers request client authentication via a certificate,
>but can tolerate unauthenticated clients as well.

Actually it's even more lopsided than that, in almost every case in which my
code's encountered a cert request from a public server (I put in a debug check
for this so I'd get feedback, see the footnote below), the server operator,
when contacted, didn't care about client authentication, and in many cases
both didn't know that their server was asking for client certs and had no idea
how to disable it when it was.  So silently failing/continuing is probably
essential to allow continued operation.

(My code originally bailed out with an error when a server requested a client
 cert and none was available, but I got lots of complaints that every other
 SSL implementation just continued without providing the cert, so the standard
 and expected behaviour seems to be to just carry on without client auth when
 the server asks for a cert).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Nov 2006 21:15:19 +1300

Bodo Moeller <[email-masked]> writes:

>language to the specification that points out that these ciphersuites should
>*usually* not be enabled.  Here is a proposal for A.5.

Isn't this just posturing though?  Since people are currently doing DH_anon
via DHE, it's not going to make much difference whether DH_anon is enabled or
not.  Or should the text include a note to say that current practice is to do
DH_anon via DHE, so enabling DH_anon isn't worth the bother and you may as
well leave it disabled?

(I'm not terribly fussed about this, people are going to program FORTRAN no
matter what language you give them, but it'd be nice if the spec at least
acknowledged current practice in order to guide both implementors and users).

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 09:48:02 +0100

> acknowledged current practice in order to guide both implementors and users).

Certainly doing "DH_anon" via DHE is currently the most frequent case
of an unauthenticated handshake found in practice, and it is has some
advantages over actual anonymous DH since clients can cache server
certificates in sort-of SSH style.  (If the client software doesn't do
this automatically, you should still be able configure your preferred
SMTP server's self-signed certificate into your TLS-aware SMTP client,
for example.)

There is some use of the actual DH_anon ciphersuites in protocols that
use other means for authentication, though.  Of course, those who
implement these specific protocols know very well which ciphersuites
they need, so they don't depend on the TLS specification explaining
these issues -- it would just be weird if the TLS specification
stricty forbade using these ciphersuites.

Here's a new text proposal for A.5.  (One additional correction here
is that I replaced "TLS 1.1", which was left in place from RFC 4346,
by "TLS 1.2", which is what draft-ietf-tls-rfc4346-bis-##.txt is
actually about.)

   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 for most purposes: 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.)

   Note that using non-anonymous key exchange but not verifying the
   certificate 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.

Bodo

---

From: <[email-masked]>
Date: Thu, 2 Nov 2006 11:17:01 +0200

Bodo Moeller wrote:

>    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

I'm not sure if "deprecated" is the right word to use; at least to me
it suggests that the feature is obsolete, and users should not expect
it to be supported in the future.

This is not the case here: DH_anon ciphersuites are just a feature
with very special and limited use cases (that are quite different 
from all the other ciphersuites). Thus, the requirement "MUST NOT be
used ... unless the application layer has specifically requested to
allow anonymous key exchange" sounds right to me. (But it should
be "TLS 1.2 implementations", not 1.1 :-)

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 10:46:03 +0100

On Thu, Nov 02, 2006 at 11:17:01AM +0200, [email-masked] wrote:

>>    requested to allow anonymous key exchange.  [...]

> with very special and limited use cases [...]

True.  "Using this mode therefore is of limited use: These
ciphersuites MUST NOT be used by TLS 1.2 implementations unless ..."?

Bodo

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Nov 2006 10:55:51 +0100

>     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.)

Thanks,
Simon

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Nov 2006 22:57:01 +1300

>   application layer is allowing anonymous key exchange.

OK, that gets my grunt of approval :-).  However, I've just thought of another
issue, is it worth noting the special case of a potential DH_anon with TLS-
PSK?  Currently there are no DH_anon_PSK suites defined, but it would seem
that one of the goals of TLS-PSK (operation on low-powered devices) would be
met by DH_anon_PSK, since the PSK avoids the need for the unnecessary cert
verification.  So maybe the text could include an additional note, something
like "In some cases additional authentication mechanisms like TLS-PSK may
obviate the need for conventional authenticated DH, since mutual
authentication is being provided by the use of TLS-PSK alongside the DH
exchange.  In other words even though a DH_anon_PSK suite would contain the
term 'anon', it's not really anonymous DH" (the same obviously goes for other
auth.mechanisms added to "anonymous" DH like SRP).

Alternatively, maybe DH_anon needs a special name when used with TLS-PSK,
something like "DH_PSK" without the "anon" bit.  This follows the pattern set
by TLS-SRP, which uses "TLS_SRP_..." even though, in conventional TLS terms,
what it's doing is TLS_DH_anon for those SRP suites that don't use server
certs.

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Nov 2006 11:29:52 +0100

> verification.  [...]

Hm, aren't you just describing the DHE_PSK ciphersuites from RFC 4279?
If they are different from what you are thinking of, what is the
difference?

Bodo

---

From: <[email-masked]>
Date: Thu, 2 Nov 2006 12:33:54 +0200

Peter Gutmann wrote:
> However, I've just thought of another issue, is it worth noting the
> special case of a potential DH_anon with TLS- PSK?  Currently there
> are no DH_anon_PSK suites defined, but it would seem that one of the
> goals of TLS-PSK (operation on low-powered devices) would be met by
> DH_anon_PSK, since the PSK avoids the need for the unnecessary cert
> verification.

RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated 
with a PSK; nothing anonymous there). Is this what you meant by
DH_anon_PSK, or something else?

Best regards,
Pasi

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 04 Nov 2006 13:21:55 +1300

<[email-masked]> writes:

>RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated with a PSK;
>nothing anonymous there). Is this what you meant by DH_anon_PSK, or something
>else?

Sort of.  It's a naming problem, the main TLS spec uses 'DH_anon' to mean 'key
exchange without certificates', while the TLS-PSK spec uses 'DHE_PSK' to mean
'key exchange without certificates (but with mutual authentication via PSK)'
(re-reading my earlier posting, I was pretty unclear on this :-).  My concern
was that phrasing the authentication check purely as "verifying the
certificate" (as in, for example, Bodo's suggested text) would cause problems
if that were taken to apply to the PSK suites (and SRP and others) where
there's no certificate to verify.  Perhaps the "verifying the certificate"
could be generalised to something like "authenticating the key exchange, for
example by verifying the certificate".  As the text currently only applies to
DH_anon it's not a problem, but if there's ever any scope creep (the text gets
applied elsewhere, copied into the security considerations section, ...) it's
going to conflict with SRP, PSK, and other non-certificate based
authentication mechanisms.

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 4 Nov 2006 08:03:18 +0100

> there's no certificate to verify.  [...]

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.)

   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.

Bodo

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 04 Nov 2006 10:23:28 +0100

>    application layer is allowing anonymous key exchange.

This looks fine!

Thanks,
Simon

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 05 Nov 2006 23:47:37 +1300

Bodo Moeller <[email-masked]> writes:

>So here's an updated proposal. 

Looks fine.  I'll shut up now :-).

Peter.

---

From: <[email-masked]>
Date: Tue, 21 Nov 2006 17:37:21 +0200

Ray Perlner wrote:
> 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.

Actually the whole text about IVs is quite long, and contains
implementation details that IMHO are likely to confuse rather than
help an implementer.

How about just replacing the whole text about IVs with something
like this?

   IV

       The Initialization Vector (IV) MUST be chosen at random, and
       MUST be unpredictable. See [SP800-38A] Appendix C for
       RECOMMENDED methods for generating unpredictable IVs.

       It is critical that the IV is not sent before the entire
       plaintext of the record is known; otherwise it is possible for
       the attacker to mount the attack described in [CBCATT].

       Note: In versions of TLS prior to 1.1, there was no IV field,
       and the last ciphertext block of the previous record (the "CBC
       residue") was used as the IV. This was changed to prevent the
       attacks described in [CBCATT].

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 27 Nov 2006 15:05:14 +0200

Ray Perlner wrote:
> 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.

Hmm... IMHO this section, as its currently written, doesn't offer
enough guidance for an implementer to get it right. Furthermore, the
text in Appendix E.2 (about what TLS-capable servers should do in SSL
2.0 compatibility mode) confuses things even further (and seems to
ignore the existence of Bleichenbacher/Klima attacks).

Then there's the issue on what the spec should say about checking the
version number in PreMasterSecret. Currently, it simply says "Client
implementations MUST and Server implementations MAY check the version
number", which is IMHO a bit vague.

Here's a suggested rephrasing for the first and fourth note
in Section 7.4.9.1:

   Note: The version number in the PreMasterSecret is the version
      offered by the client in the ClientHello.client_version, not the
      version negotiated for the connection.  This feature is designed
      to prevent rollback attacks.  Unfortunately, some old
      implementations use the negotiated version instead and therefore
      checking the version number may lead to failure to interoperate
      with such incorrect client implementations.

      Client implementations MUST always send the correct version
      number in PreMasterSecret. If ClientHello.client_version is TLS
      1.1 or higher, server implementations MUST check the version
      number as described in the note below. If the version number is
      earlier than 1.0, server implementations SHOULD check the
      version number, but MAY have a configuration option to disable
      the check.

   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. 
      [KPR03] can be used to attack a TLS server that reveals whether
      a particular message, when decrypted, is properly PKCS#1
      formatted, contains a valid PreMasterSecret structure, or has
      the correct version number.

      The best way to avoid these vulnerabilities is to treat
      incorrectly formatted messages in a manner indistinguishable
      from correctly formatted RSA blocks. In other

      1. Generate a string R of 46 random bytes

      2. Decrypt the message M

      3. If the PKCS#1 padding is not correct, or the length of 
         message M is not exactly 48 bytes:
            premaster secret = ClientHello.client_version || R
         else If ClientHello.client_version <= TLS 1.0, and
         version number check is explicitly disabled:
            premaster secret = M
         else:
            premaster secret = ClientHello.client_version || M[2..47]

      In any case, a TLS server MUST NOT generate an alert if
      processing an RSA-encrypted premaster secret message fails, or
      the version number is not as expected. Instead, it MUST continue
      the handshake with a randomly generated premaster secret. Care
      must also be taken to avoid leaking information about the error
      situation via log files, or other channels.
    
      The RSAES-OAEP encryption scheme defined in [PKCS1] is more
      secure against the Bleichenbacher attack. However, for maximal
      compatibility with earlier versions of TLS, this specification
      uses the RSAES-PKCS1-v1_5 scheme. No variants of the
      Bleichenbacher attack are known to exist provided that the above
      recommendations are followed.

And rewrite appendix E.2 as follows (changing SHOULD to MUST 
for sending the 0x03 padding):

E.2. Avoiding man-in-the-middle version rollback

   When TLS clients fall back to Version 2.0 compatibility mode, they
   MUST use special PKCS#1 block formatting. This is done so that TLS
   servers will reject Version 2.0 sessions with TLS-capable clients.

   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
   the right-hand (least-significant) 8 random bytes of the PKCS
   padding (not including the terminal null of the padding) for the
   RSA encryption of the ENCRYPTED-KEY-DATA field of the
   CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random).

   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
   padding bytes are 0x03. If they are not, the server SHOULD generate
   a random value for SECRET-KEY-DATA, and continue the handshake
   (which will eventually fail since the keys will not match).  Note
   that reporting the error situation to the client could make the
   server vulnerable to attacks described in [BLEI].

Comments?

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Nov 2006 21:27:16 +0100 (MET)

>       situation via log files, or other channels.

I once had to analyze a handshake problem with a particular's vendor
SSL accellerator (server-side middle-box), where that box contained
an error in the RSA encryption and every once in a while sent garbage,
i.e. there was no recognizable PKCS#1 padding when RSA-decrypting
on the backend server.  I was lucky that our SSL implementation did
not use the OpenSSL approach, where this kind of error is not only
hidden from the peer, but also from the local caller.

Completely hiding the decryption failure from the local caller
creates a serious supportablility issue, so please be more careful
with the recommendation.  One should be careful, though, that the
local error reporting, which may be as simple as setting an integer
value to a particular value, does not result in a measurable timing
difference.  It is important that the local caller is able to
retrieve the real reason why the session establishment failed,
not "MAC failure" (as the SSL alert on the wire suggests") but
RSA-decryption failure.

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Nov 2006 15:49:13 +1300

Martin Rex <[email-masked]> writes:

>Completely hiding the decryption failure from the local caller creates a
>serious supportablility issue, so please be more careful with the
>recommendation.

Another thing that should really be mentioned in the text (which I've pointed
out before) is that the requirement to continue makes for a marvellous DoS
attack, just blindly send a string of TLS handshake packets with a garbage
value for the RSA-encrypted data and the server has to go through the entire
rest of the handshake.  In some situations (e.g. low-powered devices) this
"defensive" measure may be an own-goal.

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Nov 2006 12:01:46 +0100

> with the recommendation.  [...]

"Care must be taken to avoid leaking information" is exactly right.
It is true that supressing the detailed error information can be a
problem for debugging, but this just means that the standard
production setup isn't always adequate for debugging purposes.
(E.g. software could have a switch that enables more detailed
log file entries that reveal when a padding error was detected.)

The problem is that the adversary might have access, however limited,
to the server system.  Even if the adversary can't actually read the
TLS server logfile, we may have an "ls -l" attack if the error
messages are of different length for different error cases: merely
observing the length of the logfile may allow the adversary to
distinguish between different error cases, and thus to perform the
attack.

You still can record the information if you desire, you just have to
thoroughly make sure you don't leak it to the adversary.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Nov 2006 12:07:03 +0100

> "defensive" measure may be an own-goal.

Is this relevant?  The adversary might just as well send valid
RSA-encrypted data (which is quite quickly done for e=65537) to keep
the server busy.  Even with invalid RSA-encrypted data, the server
already has spent considerable effort on RSA decryption when it can
finally check the padding -- so it's not as if servers could
effortlessly handle the DoD attack that you described without the
Bleichenbacher defense.

Bodo

---

From: <[email-masked]>
Date: Tue, 28 Nov 2006 13:32:40 +0200

> not "MAC failure" (as the SSL alert on the wire suggests") but

I do agree that such debugging features are useful in many 
circumstances -- but there are other channels than timing
that may leak information. How about rephrasing this:

   "Care must also be taken to avoid leaking information about
   the error situation via log files, or other channels."

as follows:

   "It may be useful to log the real cause of failure for
   troubleshooting purposes; however, care must be taken to 
   avoid leaking the information the attacker (though, e.g.,
   timing, log files, or other channels)."

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 28 Nov 2006 13:35:35 +0200

Peter Gutmann:

> Another thing that should really be mentioned in the text (which
> I've pointed out before) is that the requirement to continue makes
> for a marvellous DoS attack, just blindly send a string of TLS
> handshake packets with a garbage value for the RSA-encrypted data
> and the server has to go through the entire rest of the handshake.
> In some situations (e.g. low-powered devices) this "defensive"
> measure may be an own-goal.

The most resource-consuming part of the handshake is the RSA
decryption, and this we have to do before we can detect any padding
errors. So I'm not sure if continuing the handshake really makes the
situation any worse DoS-wise...

(Especially remembering that we don't have any good alternatives;
reporting the error leads to revealing your private key.)

Best regards,
Pasi

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Nov 2006 00:42:17 +1300

Bodo Moeller <[email-masked]> writes:
>Is this relevant?  The adversary might just as well send valid RSA-encrypted
>data (which is quite quickly done for e=65537) to keep the server busy.  

TLS doesn't have any anticlogging mechanism, so all an attacker needs to do is
open a socket, write a pre-generated string of TLS client messages, and close
the socket again.  In the meantime the server has to go through a full TLS
handshake to discover that it's just a DoS.  This makes that attack it waaaay
too asymmetric for my liking...

Peter.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 28 Nov 2006 11:53:25 +0000

> reporting the error leads to revealing your private key.)

Does it? I thought a successful attack revealed a premaster secret, not
the actual private key.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Nov 2006 13:23:33 +0100

> too asymmetric for my liking...

Yes, I understand that -- what I meant is, would it significantly help
not to have to do the Bleichenbacher countermeasure?  I don't think
so, because even without the countermeasure the same attack could
easily keep the server very busy.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Nov 2006 13:28:46 +0100

> Does it? I thought a successful attack revealed a premaster secret, not

True: the attack allows an adversary to *use* you private key, but not
to *obtain* it.

(No-one knows for sure if an oracle that computes e-th roots modulo
some composite integer n, which is what RSA decryption does, can be
used to obtain the inverse of e modulo phi(n) or -- equivalently -- to
factor n.  Thus, there is no known algorithm to use an RSA decryption
oracle, such as the one involved in the Bleichenbacher attack,
to obtain the private RSA key.)

Bodo

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 28 Nov 2006 08:26:15 -0500

> situation any worse DoS-wise...
If we want to deal with DoS attacks at that layer, we could standardize
the Dean/Stubblefield TLS client puzzle scheme.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Martin Rex <[email-masked]>
Date: Tue, 28 Nov 2006 23:52:32 +0100 (MET)

>    timing, log files, or other channels)."

Fine with me.

               ... the information to an attacker ...
                                   
maybe.

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Nov 2006 17:24:11 +1300

Bodo Moeller <[email-masked]> writes:
>Yes, I understand that -- what I meant is, would it significantly help not to
>have to do the Bleichenbacher countermeasure?  I don't think so, because even
>without the countermeasure the same attack could easily keep the server very
>busy.

I think specifically building in a countermeasure may be overkill, but since
the text mentions various implementation considerations it should probably
also mention this one in case it's a concern for anyone.  In particular the
fact that even a small botnet can, via source address forgery sending large
numbers of pre-generated handshake packets, bring pretty much any TLS server
to its knees (and I'm surprised this DoS hasn't been tried yet) should be a
security concern.  There's no pressing need to fix it (yet :-), but the text
should at least mention it as something that implementors may want to
consider.

Peter.