>From the discussions in this list and some offline conversations it is clear
that people like OPTLS for its features but are concerned with the issue of
"delegation", namely, the need for the server to create certificates for
static DH keys g^s by signing (using the RSA key in the server's
certificate)
the key g^s, the validity period (T1,T2) and possibly some other
information.
I'll call this signature a sub-certificate or subcert (some suggested
calling
this a proxy certificate but I prefer not to use established terminology
since
I am not sure what the exact semantics/connotations of these terms).

Here is a summary of the concerns and some of the available techniques to
deal
with them.

* The delegation concerns do NOT exist in a model where the attacker either
  gets full control of the private signing key (e.g., steals it) or
otherwise
  has no access to it. Indeed, in this case either the  key is secure and
the
  attacker cannot produce subcerts or the key is fully compromised and one
  cannot possibly provide server security (in this or any previous version
of
  TLS).

* Thus, delegation concerns only arise when assuming an attacker that cannot
  steal the signing key but can get temporary access to a signing device and
  create a few signatures on arbitrary data. In such case, the attacker can
  generate subcerts for keys g^s for which it knows the secret key s, hence
  allowing him to impersonate the server against any client accepting this
  subcert.

* I am not sure how common the above "partial exposure" problem is in
practice
  but note that if the signing key was only used to generate TLS 1.3
subcerts
  then it could be well guarded since it would be used rarely and never
needed
  online. This would be the case if servers equipped themselves with
signature
  certificates solely used for this purpose (rather than using the same
  certificate in protocols like TLS 1.2 that require online signatures).

NOTE: One way of using a TLS 1.3 RSA key would be to generate a bunch of
subcerts for g^s values in all the EC groups that the server supports and
then
DESTROY the signing key. (This is equivalent, functionally and
security-wise,
to getting DH certificates for all these groups without requiring the CA to
issue DH certificates at all!)

* Assuming that servers will not want to get certificates for use with TLS
1.3
  only (why not?), then we need to address the above subcert forgery
scenario
  where the atacker gets limited access to the signing key. An imperfect but
  effective solution is to only issue subcerts with short validity period,
  i.e.  where the difference T2-T1 is small. In this case the attacker with
  temporary access to the signing key can only create a limited number of
  subcerts covering a limited time span.

Operational note: It is the servers' responsibility to create such
short-lived
subcerts but it is the clients' responsibility to check the subcerts are
indeed short-lived (otherwise an attacker can generate a long-lived subcert
that the client will accept).

* Clients with clocks with significant deviations from the correct time will
  have trouble accepting valid subcerts and may be induced to accept old (or
  into-the-future) subcerts. I can imagine this to be a problem. But is it
  enough to abandon the benefits of a ECDH-based solution like OPTLS?

* The acceptable validity periods can be fixed by the protocol or can be
part
  of the "negotiation" where the client will say which validity-period
lengths
  are acceptable to him and the server will send an error message if it does
  not support such periods. Or the server can simply send the subcert with
the
  shortest validity period which is still valid and the client accept it
  depending on his clock and policy.

Note: One could accommodate, in principle, a period length of 0, meaning a
subcert that is only valid instantaneously; in other words, this would be a
per-session signature on g^s that will also include the client nonce.

* There is no need to have a revocation mechanism for subcerts. The rule is
  that subcerts are not accepted once the RSA certificate is expired or
  revoked. Hence, the revocation of the RSA certificate implies revocation
of
  all subcerts signed with it.

FINAL NOTE: The above issues will be eventually solved with servers getting
certificates for use with TLS 1.3 (either ECDH certificates or signature
certificates used as explained in the first NOTE above).

Hugo


On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams <nico@cryptonector.com>
wrote:

> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
> > > On Nov 11, 2014, at 7:33 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > > That the "sub-cert" needs either a revocation scheme (not likely) or a
> > > short lifetime.  The latter puts this on a par with session resumption,
> > > thus making one (well, me) wonder what the advantage to the static DH
> > > concept would be.
> >
> > There is a revocation scheme. If the private ECDH key is lost, you
> > revoke the certificate, thereby invalidating the delegation.
>
> Ah, good point!
>
> > > We could put static DH keys in DNSSEC and learn them that way, which
> > > would get us 0rt.
> >
> > Another possibility is to place the ECDH public key in a certificate
> > extension. This gives it a lifetime as long as the certificate, and it
> > doesn’t matter whether the “regular” certificate public key is RSA or
> > ECDSA or anything else.
>
> Sure, certs could have multiple subject public keys.  That'd be a very
> nice.  A cert could have an encryption key, a different signature key,
> and a key agreement key.
>
> > It removes the need to use signatures at all by the server. Not even
> > once.
>
> Yes.  I like this.
>
> Nico
> --
>