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

[Nico Williams <[e-mail]>]

On Tue, Nov 11, 2014 at 09:46:38AM -0500, Hugo Krawczyk wrote:
> I am surprised to see such an abrupt decision to drop consideration of
> OPTLS. [...]

I didn't see such a decision.  Just a lot of questions.

> 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. [...]

Yes, though there'd be no 0rt the first time a client meets a server
(unless DANE is used).

> 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

That and the fact that we can't have intermediate CA certs because of
the lack of implementation (and deployment) of naming constraints, nor
can we have proxy certs [RFC3820] -I think, but correct me if I'm wrong-
for similar reasons.

(Note that RFC3820 proxy certs have no revocation mechanism.)

> the future - actually, as I argue below, there are advantages of sub-certs
> for g^s over a long-term ECDH certificate.

Isn't "sub-cert" ~= proxy cert?

> 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
> [...]

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.

We could put static DH keys in DNSSEC and learn them that way, which
would get us 0rt.

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

Server certificates can be revoked (wellll).  Delegations can't be, not
without losing the optimization value of delegation in the first place.
That seems like a deal killer for anything other than short-lived
delegation.

Nico
--