[TLS] Re-thinking OPTLS

[Hugo Krawczyk <[e-mail]>]

>From information I received regarding the meeting in Honolulu (which I did
not
attend and whose minutes are still unpublished) I gather that there was not
enough support to continue consideration of the OPTLS proposal. This lack of
support was based on three objections:

- It is a "last minute" proposal that will delay the publication of TLS 1.3.

- The "delegation" issue: An attacker that can gain access to the server's
  signing box, without necessarily learning the signing key, can obtain a
  signature on a static DH key and use it to impersonate the server.

- The performance advantage of OPTLS relative to RSA signing is diminished
  when comparing to (current) TLS 1.3 with ECDSA signatures.

I think these are important points but I feel that they were not given
proper
consideration, in particular, since there was not enough time to digest the
proposal before the Honolulu meeting. I believe that OPTLS offers
significant
security and functional advantages over the current TLS 1.3 proposal and
should not be dismissed without a more focused discussion.  This is
particularly so if we can clear the issue of delegation that was the main
trigger to the change of sentiment on OPTLS from positive to "hesitating".

In this note, I will address the three issues. The arguments are incomplete
in
the interest of not making this long email even longer. I will be happy to
hear your feedback and expand on any issues that need further
clarifications.

*** The "last minute" objection ***

This proposal is indeed coming at a late point in the process of specifying
TLS 1.3. However, we are planning for a protocol that we hope will serve us
for many years; a possible delay of a few weeks should not be a determining
consideration. We must approach the design of TLS 1.3 with a
*forward-looking*
approach that considers evolving crypto technology, addresses a set of core
requirements and leaves some flexibility for future functionality.
TLS history shows that the protocol should be based on sound cryptographic
design requiring as little crypto machinery as possible, and providing a
consistent logic for the different modes of the protocol. OPTLS is rooted in
this approach, building fully on a single underlying mechanism -
Diffie-Hellman for both forward secrecy and authentication - and extending
naturally to other authentication settings such as 0-RTT, pre-shared key and
session resumption. Many of the benefits of OPTLS have been discussed in the
original thread in this list and will not be reiterated here in detail.
Please refer to these messages for more background:

https://www.ietf.org/mail-archive/web/tls/current/msg14385.html
https://www.ietf.org/mail-archive/web/tls/current/msg14592.html
https://www.ietf.org/mail-archive/web/tls/current/msg14601.html

*** The delegation issue ***

I would now like to address the very valid concerns with using the server's
existing signature key to sign static DH keys (a signature I refer to as a
"subcert"). This has been the only technical objection to the protocol
raised
in this list and therefore I see its resolution as a necessary (and
hopefully
sufficient) condition for the adoption of the protocol. For some previous
discussion on this issue see above cited messages, particularly the last
one.
Essentially, the problem is that the server's signature key becomes a
"certifying key" for static DH keys and therefore its unauthorized usage can
lead to adversarially-chosen static DH keys that allow the attacker to fully
impersonate the server. This is not worse than an attacker stealing the
signature key and using it to impersonate the server in current TLS.
However, in the non-typical, but possible, scenario where an attacker can
gain
access to the signing functionality as a black-box (i.e., without learning
the
signing key) and obtain a signature on a message of its choice, this becomes
a serious vulnerability. A particularly "ugly" case is that of a server that
hasn't even upgraded to TLS 1.3 but that can be impersonated as a TLS 1.3
server if the attacker gets a signature of the server on a static DH key of
the attacker's choice.

One clean solution to the problem is to equip servers with new certificates
that indicate use of the certified key for TLS 1.3. These can be either ECDH
certificates or signature certificates (RSA, ECDSA or your favorite
signature
algorithm). In the case of ECDH certificates, no subcert or any form of
signature is needed to run OPTLS. If the server's certificate is for a
signing
key then the server needs to send to the client a subcert with a signature
on
its static DH key. However, in this case, the certified key will only be
used
to sign subcerts - never as an online signature, hence can be afforded
better
protection. Indeed, the key can be stored offline and used only when new
subcerts (for new static DH keys) are needed, or it can be protected even
better by using it to to produce multiple subcerts (for multiple validity
periods and/or multiple EC groups) and then be destroyed. For those who
still
feel this is not secure enough, the choice is simple: Use ECDH certificates
and avoid the whole delegation issue. Note that ECDH certificates would be
the
simplest way of supporting a protocol like OPTLS. There is, however, one
issue
with ECDH certificates, namely, a server will need multiple certificates to
support different groups. This is where server-signed subcerts are
convenient.
Note, however, that this is an advantage only when using RSA signatures.
When the signature is ECDSA, we are back to the problem of requiring
multiple
ECDSA certificates for multiple groups. In this case, there seems to be no
advantage on having signature certificates. Fortunately, OPTLS can work with
any of these certificate types, leaving these choices to individual servers
and accommodating any future (possibly unforeseeable) preferences.

The bottom line is that the potential delegation vulnerabilities are
addressed
by servers obtaining new certificates for use with TLS 1.3. However, what
about a server that is interested to upgrade to 1.3 (e.g. for providing PFS)
but wants to keep using his TLS 1.2 signature key also with 1.3?
For this case, I proposed (see third message above) a small tweak to the
original OPTLS in which the server signs the static DH key together with the
client's nonce, hence preventing any form of delegation attack. This forgoes
the performance advantage of OPTLS relative to current TLS 1.3, but it
facilitates a transition period until a server acquires a new certificate
for
use in TLS 1.3. The nice thing about this tweak is that the only change in
the
protocol's spec is replacing the validity period in the subcert with the
client's nonce.  *Everything* else in the protocol stays the same; in
particular, it preserves all of the non-performance OPTLS advantages
(including optional 0-RTT support at no extra cost and a single logic for
all
the protocol modes). It also presents a real incentive for servers to
upgrade
to TLS 1.3 (and TLS 1.3 certificates) as it saves the cost of RSA decryption
in each session. As we know, performance gains are a better motivator than
just added security.

*** OPTLS vs ECDSA ***

The argument was made that when people will start running TLS 1.3 (as
currently specified) with ECDSA, the dramatic performance advantage of OPTLS
relative to RSA signatures will diminish. That is true. But the OPTLS
advantages are well beyond performance. In particular, as said above, OPTLS
uses a single cryptographic mechanism, Diffie-Hellman, for all its
functionality and does not depend on signatures (except for certification).
Current TLS 1.3 depends on both DH and signatures, hence reducing its
security
to the weaker of the two.  In addition, 0-RTT cannot be supported with a
server's signature key and it requires adding a static DH key (or other PK
encryption keys) to the server's public keys. Hence the signature is
duplicating a functionality that can be provided by the static DH key only
(as
OPTLS does). There are also specific problematic aspects with ECDSA. For
one,
there is the issue of supporting multiple groups, hence necessitating
multiple
certificates (for the same "price", one can run OPTLS with ECDH
certificates,
avoiding signatures, subcerts, and their associated complexities and costs,
including bandwidth).  ECDSA requires deployment at servers and clients (in
addition to ECDH that's needed for forward secrecy anyway), and presents
non-trivial implementation issues for performance and to resist side-channel
attacks (these implementation  problems are specific to ECDSA signing and do
not apply to ECDSA verification as may be needed for verifying
certificates).
OPTLS avoids these obstacles by solely building on the necessary and
simpler-to-implement ECDH mechanism. Finally, ECDSA is vulnerable to the
full
compromise of the signing key upon the leakage of a single ephemeral
quantity.
OPTLS does not suffer of this problem and actually increases security over
the
ephemeral DH key computed in TLS 1.3 by feeding g^{xs} into the KDF that
produces application keys.

I respectfully ask for the re-consideration of OPTLS by the WG as a possible
enhancement of TLS 1.3 design.

Thanks,

Hugo