Re: [TLS] OPTLS: Signature-less TLS 1.3

[Hugo Krawczyk <[e-mail]>]

Wait, wait, wait...

I am surprised to see such an abrupt decision to drop consideration of
OPTLS. There is little information in the minutes as for the rationale for
this move although it seems to be entirely based on the handling of
static-DH certificates and the understanding that in the future one can
still run TLS 1.3 with ECDSA and/or ECDH certificates.

Let me address these issues and the multiple advantages of OPTLS that need
to be considered. Please bear with me in spite of the long email. Since I
will not be in Hawaii (I wish I was...) take this in lieu of a presentation
at the WG meeting (and pardon the advertisement pitch, I believe it is fair
and well-founded).

First, note that if we had ECDH certificates then this whole issue of how
to sign the static DH key g^s would be moot. You would use that certificate
to vow for the server's static DH key. Security would be based on the
protection of s exactly as it is based on the security of a private signing
key today. In particular, the key s would need to be kept online with the
same vulnerabilities (and potential protection) of a signing key today.

The whole reason to create a "sub-certificate" for g^s by signing it with
the server's certified signature is that we currently only have
certificates for signature keys, not ECDH. This may or may not change in
the future - actually, as I argue below, there are advantages of sub-certs
for g^s over a long-term ECDH certificate.

So what is the concern that has been voiced regarding the use of sub-certs
for g^s? That the leakage of a private key s that was sub-certified allows
to impersonate the server for the validity period of that sub-certificate,
and that clients with skewed clocks will be accepting it beyond the
intended validity period. This is true but not different than the situation
with current certificates. In particular, the validity period of the
sub-cert will never exceed that of the signing certificate. How about
revocation? It requires the main certificate revocation exactly as needed
now.

So none of these issues is worse than vulnerabilities of signing keys today.
Actually, there are two non-trivial advantages to the sub-cert approach:
 - clients with good clocks (or small skews) will not accept g^s much past
its validity period, which would be typically much more limited than the
main signing cert. Clients with terrible skews will never be in worse shape
than they are today with respect to validating the signing certificate.
-  a server can issue multiple g^s keys for availability, distribution,
sub-domain use, etc. and to support different groups ECDH groups - which
need to be supported anyway for PFS also in a signature-based protocol.
(There is also the ability to support online retrieval of currently
validated sub-certificates via protocols such as DNSSEC or other specific
mechanisms, even though there seems to be little enthusiasm for this
option, at least currently)

The only downside I can see for sub-certification of g^s is for cases where
protection of an online signature key (as needed today) is better than the
one affordable to the key s, e.g. with current HSMs that support signing
but not ECDH. But this is the price of a looking-forward transition period
as opposed to proposals that keep us tied to the sub-optimality of past
solutions. It needs to be considered in light of the many advantages of a
signature-less protocol as claimed here.

Let me now address the claim that in the future we will have ECDSA
certificates which would enable a signature-based protocol with less cost
than RSA signing today. This claim is mostly true but ignores some
important aspects of the use of ECDSA:
- The wide use of RSA in certificates is not going away any time soon - so
the very significant performance advantages of OPTLS vs a RSA-implemented
signature-based protocol is going to be enjoyed for long time (actually, it
may be a main motivation for adoption of signature-less TLS 1.3 in addition
to PFS)
- The total time of sign+verify in ECDSA is larger than the time of
static-DH authentication used in OPTLS.
- ECDSA presents definition and implementation complexities that do not
exist with ECDH, in particular tied to specific EC groups. In particular,
this is likely to postpone adoption of ECDSA.
- Online ECDSA signatures amplify the vulnerability of the long-term ECDSA
signing key to the leakage of ephemeral values (in ECDSA, as in other
Schnorr-like signatures, there is a per-signature random value that if
revealed, it fully reveals the long-term private signing key). Such
vulnerability does not exist in OPTLS.
- Signature-less protocols have a privacy advantage in providing plausible
deniability, especially when compared to protocols (as current 1.3) that
sign the peer's identity (I wrote on this in a previous message to this
list).
In addition, signature-less protocols can take advantage of sub-certs as
noted above. Even when the algorithm to sign these sub-certs will be ECDSA,
it will allow the use of Offline ECDSA hence ameliorating the above
vulnerability of ECDSA to ephemeral disclosure.

And now to summarize some of the general advantages of ECDH-based (and
signature-less) protocols and some specific advantages of OPTLS:
- 0-RTT support required static ECDH keys (or semi-static, exactly as in
OPTLS) - thus in a signature-based protocol this support would be pure
overhead
- Critical performance gain relative to per-session signing with RSA (an
advantage that will most probably stay with us for long time)
- Compatibility with the already needed mechanisms to provide PFS (hence
amortizing any cost of the underlying crypto)
- Compatibility with pre-shared key authentication: simply replace g^{xs}
with PSK.
- Cryptographically, it relies on the ECDH security of the underlying EC
groups rather than relying on this security PLUS the security of signatures
(which means relying on the weaker of the two primitives)
- Other advantages mentioned above: Sub-cert time limitation and support
for multiple static ECDH keys if so desired, specific advantages with
respect to ECDSA-based protocols (complexity of ECDSA and vulnerability to
ephemeral information), privacy via deniability, offline signatures
(specially significant with ECDSA).

Finally, the advantage of a protocol built with cryptographic logic, not as
a accidental result of many years of patches. I believe the WG has delayed
or never implemented in the past significant changes such as
Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we can make
it right from the begining.

Hugo