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

[Daniel Kahn Gillmor <[e-mail]>]

On 11/10/2014 04:12 PM, Nico Williams wrote:
> The time should be relative, as a TTL.

relative to what?

If the credential is standalone (e.g. in such a way that the signing key
can be kept offline) then the TTL established can be replayed by an
attacker who takes control of the DH secret to extend the lifetime of
the delegated credential, right?

if the credential isn't standalone (i.e. if it's accepted by the client
based on its inclusion in the signed handshake which has been
authenticated by a signature from the signing key), then we aren't in a
signature-less TLS scheme.

if it's not relative, but it's long-lived, then we introduce a new
revocation problem.  if it's not relative and it is short-lived, then we
introduce interesting clock skew issues (though perhaps those are the
same as OCSP-must-staple clock skew issues?)

None of this is to say that delegation is a terrible idea, but just that
the details matter and it's not something to casually adopt without
understanding the tradeoffs we're taking.

and those tradeoffs are complex enough that they seem to overwhelm the
possible performance gains from the OPTLS proposal.  (esp. when there
are other ways like ECDSA certs that give comparable performance gains).

> "This resumption ticket is good for 2 hours."
> 
> "This DH pubkey is good for 2 hours."
> 
> "hours" is good.  "days" is not.

I agree that short-lived is nice; I think it also possibly removes the
pro-OPTLS argument about keeping the signing keys offline.  (maybe
that's ok)

But without a concrete specification of what the delegation mechanism
looks like, the properties of the deployed proposal end up being very
different.

	--dkg